Nouvelle alarme
A la création d'une nouvelle alarme, XT3 initialisait son heure selon une option :
Cela obligeait presque toujours à modifier les minutes, les évènements étant généralement à heure "pile".
XT4 ne propose plus cette option, mais calcule l'heure pile après la prochaine (alarme créée à 10h18) :
(La prochaine heure pile n'est pas utilisée, car si une alarme est créée à 10:59 et que la saisie de l'heure est oubliée, XT4 mettrait 11:00 et l'alarme se déclencherait trop rapidement.)
Sam 26/01/2013 - Actualités
-
Xavier
- Administrateur du site
- Messages : 817
- Enregistré le : mer. 22 juin 2011 18:25
Sam 26/01/2013 - Actualités
Vous n’avez pas les permissions nécessaires pour voir les fichiers joints à ce message.
-
Denis
- Messages : 180
- Enregistré le : jeu. 23 juin 2011 09:21
Re: Sam 26/01/2013 - Actualités
Il faut pouvoir paramétrer cela dans les options 
chacun ayant une très bonne idée de l'algo qu'il faudrait.
Par exemple, pourquoi pas dire: prendre l'heure courante, lui rajouter un quart d'heure (pour etre sur de la saisie) puis prendre la première demi-heure pleine (et pas l'heure entière) ?
chacun ayant une très bonne idée de l'algo qu'il faudrait.Par exemple, pourquoi pas dire: prendre l'heure courante, lui rajouter un quart d'heure (pour etre sur de la saisie) puis prendre la première demi-heure pleine (et pas l'heure entière) ?
-
Xavier
- Administrateur du site
- Messages : 817
- Enregistré le : mer. 22 juin 2011 18:25
Re: Sam 26/01/2013 - Actualités
Je ne suis pas contre à priori, car ça dépend de l'utilisation de chacun, pour ma part je n'utilise les heures que pour les réunions, et celles-ci commencent toujours à heure pile.DMo a écrit :Il faut pouvoir paramétrer cela dans les options
Par exemple, pourquoi pas dire: prendre l'heure courante, lui rajouter un quart d'heure (pour etre sur de la saisie) puis prendre la première demi-heure pleine (et pas l'heure entière) ?
Si tu penses avoir besoin d'un ou plusieurs autres algos, liste-les moi STP. (Avec un exemple d'utilisation...
)-
Xavier
- Administrateur du site
- Messages : 817
- Enregistré le : mer. 22 juin 2011 18:25
Sam 26/01/2013 - Actualités
Données Agenda
Les Properties des données de l'Agenda, telles que décrites ici ont été légèrement améliorées par l'ajout d'attributs dédiés "Alarm" et "Repeat" car il y a trop de bugs dus à une mauvaise interprétation du modèle précédent, la distinction entre les propriétés facultatives et dépendantes n'y étant pas clairement définie.
Les Properties des données de l'Agenda, telles que décrites ici ont été légèrement améliorées par l'ajout d'attributs dédiés "Alarm" et "Repeat" car il y a trop de bugs dus à une mauvaise interprétation du modèle précédent, la distinction entre les propriétés facultatives et dépendantes n'y étant pas clairement définie.
Vous n’avez pas les permissions nécessaires pour voir les fichiers joints à ce message.
-
Xavier
- Administrateur du site
- Messages : 817
- Enregistré le : mer. 22 juin 2011 18:25
Sam 26/01/2013 - Actualités
Transformations
La transformation des données décrite ici continue.
Une tâche est maintenant correctement transformée en évènement unique et vice versa par les opérations de copie et déplacement dans la liste. (Le drop sur une cellule du Calendrier reste à faire.)
La transformation d'un évènement répétitif en tâche sera la prochaine étape. Elle demandera une désinstanciation (transformation en évènements uniques des instances surchargées d'un évènement répétitif), ce sera donc l'occasion de réutiliser le service Un_Instanciate qui a été écrit plus tôt dans la journée afin de gérer la perte de répétition d'un évènement répétitif déjà instancié.
Côté bugs, le plus méchant des crashs a pu être neutralisé par un try...except, l'équivalent Delphi du trap_error. Il apparaissait de façon aléatoire à la fermeture de l'application, quelque chose tentant de manipuler les données de l'Agenda alors que l'outil est déjà fermé et que les données n'existent donc plus. Il faudra creuser plus loin pour trouver la raison de cet accès aux données et corriger proprement. Sinon, il reste d'autres crashs, mais reproductibles donc clairement dus à des bugs.
La transformation des données décrite ici continue.
Une tâche est maintenant correctement transformée en évènement unique et vice versa par les opérations de copie et déplacement dans la liste. (Le drop sur une cellule du Calendrier reste à faire.)
La transformation d'un évènement répétitif en tâche sera la prochaine étape. Elle demandera une désinstanciation (transformation en évènements uniques des instances surchargées d'un évènement répétitif), ce sera donc l'occasion de réutiliser le service Un_Instanciate qui a été écrit plus tôt dans la journée afin de gérer la perte de répétition d'un évènement répétitif déjà instancié.
Côté bugs, le plus méchant des crashs a pu être neutralisé par un try...except, l'équivalent Delphi du trap_error. Il apparaissait de façon aléatoire à la fermeture de l'application, quelque chose tentant de manipuler les données de l'Agenda alors que l'outil est déjà fermé et que les données n'existent donc plus. Il faudra creuser plus loin pour trouver la raison de cet accès aux données et corriger proprement. Sinon, il reste d'autres crashs, mais reproductibles donc clairement dus à des bugs.