Mer 23/01/2013 - Actualités

[Xavier]

Copies et déplacements

Agenda.png

Les copies et déplacements vont fonctionner différemment selon la zone cible :

• Si la destination est dans les Dossiers, on gère le dossier et ignore les dates.
• Si la destination est dans le Calendrier ou l'Agenda, on gère les dates uniquement

Le comportement sera donc :

• De Dossiers vers Dossiers : fonctionnement classique, une donnée, un dossier ou un arbre entier est copié ou déplacé, aucune date n'est modifiée. Exemple : déplacement de tâches vers un dossier "Projet A" nouvellement créé.
• D'Agenda vers Dossiers :
  • Pour une période ou un évènement unique : l'objet est copié ou déplacé dans le dossier cible.
  • Pour un évènement répétitif : l'évènement répétitif ainsi que de toutes ses surcharges seront copiés ou déplacés dans le dossier cible. Il n'y aura pas de message proposant de ne déplacer qu'une occurrence.
• D'Agenda vers Agenda (uniquement en mode "Semaine") :
  • Pour une période ou un évènement unique : la date est modifiée. Exemple : report d'un évènement.
  • Pour un évènement répétitif :
    • S'il est déjà présent à la date cible, rien n'est fait.
    • S'il n'est pas présent, il sera instancié comme décrit hier (instance d'annulation à la date source + instance de surcharge avec date modifiée à la date cible).
• D'Agenda vers Calendrier : même comportement que d'Agenda vers Agenda sauf que ce sera possible même en mode "Jour".

Les opérations (hors drag-and-drop) fonctionnent déjà bien sur les données non répétitives.

La copie ou le déplacement d'un évènement répétitif nécessite la prise en charge de ses instances surchargées. Le système de Couper/Copier/Coller actuellement utilisé dans XT4 est mono-instance. Il utilise un pointeur vers une donnée, et va donc être remplacé par une liste de pointeurs. Ce changement permettra d'ailleurs d'activer la sélection multiple dans les différents outils.

[Xavier]

Wanted : "m:obj.find"


XT4 utilise un modèle de données hiérarchisé, similaire à un arbre XML.
La hiérarchie est assurée grâce à un double lien :

• Chaque parent a la liste de ses enfants.
• Chaque enfant a un lien vers son parent.

Jusqu'à présent, toutes les recherches dans l'arbre étaient soit :

• Ciblées : cherchant un objet selon son Ident (unique).
• Itératives ou récursives : bouclant sur tous les enfants et petits-enfants via :
  • Un Count de la liste des enfants d'un parent.
  • Un accès direct à ces enfants grâce à leur Index dans la liste via une boucle [0..(Count - 1)].

Hier, la suppression des instances surchargées d'un évènement répétitif a levé le premier besoin d'une instruction de type "m:obj.find".
Comme il n'y a pas de notion de backtrack en Delphi, le problème a été contourné via une boucle while :

Code : Tout sélectionner

Instance_Data := Folder_Data.Search('SuperEvent', Super_Ident, True);
while	Instance_Data <> Nil
do	begin
	Instance_Data.Delete;
	Instance_Data := Folder_Data.Search('SuperEvent', Super_Ident, True);
end;

Evidemment cette astuce ne fonctionne que dans ce cas précis, car la donnée trouvée est supprimée et la recherche suivante trouve donc un autre objet.


Aujourd'hui, il s'agit de copier dans un Buffer les instances surchargées d'un évènement répétitif. Sans le Delete, le code ci-dessus part dans une boucle sans fin.

Deux options sont à l'étude afin de trouver une solution proche des instructions FindFirst et FindNext que Delphi propose pour boucler sur des fichiers :

• 1 - La recherche gère les "déjà trouvés" dans une liste en mémoire, et continue donc à chercher quand elle passe sur un objet déjà renvoyé. Facile à implémenter mais coûteux en mémoire et en traitement, la totalité de l'arbre étant reparcourue à chaque tour de boucle.
  2 - La recherche conserve en mémoire le chemin du dernier objet trouvée, pour ne reprendre la recherche qu'après ce point. Le chemin serait à priori une liste de chiffres représentant les Index, par exemple [0, 3, 5] correspondrait à DataRoot.Children[0].Children[3].Children[5]. Optimisé mais sans doute moins évident à implémenter.

[Xavier]

SearchAll


A la réflexion, tenter de faire backtraquer un Search ne servirait pas à grand chose tant que la boucle appelante ne serait pas capable de gérer ce backtrack...

Et comme le but de cette recherche est de peupler le nouveau Buffer de Copier/Coller, un nouveau service SearchAll a été créé.
Il est basé sur le Search initial, sauf qu'il ne s'arrête pas dès qu'un objet est trouvé.
Il mange en entrée une liste, y ajoute un pointeur vers chaque objet trouvé, et la renvoie en sortie. (Un pointeur pesant 32 bits, une liste d'un millier d'objets pèsera 4 Ko.)

Ce passage de liste en récursif évite la créations de sous-listes à chaque niveau et contourne l'apparente absence d'instruction de merge de listes.

[Denis]

sinon tu aurais pu jouer avec des index: récupérer l'index de l'élement trouvé first, puis le passer à ta fonction Search (comme index de début de recherche-1).
Mais BV pour SearchAll

[Xavier]

Copies complexes


Lors d'une copie d'un évènement répétitifs et de ses instances surchargées, il a fallu insérer des routines afin de recalculer un nouvel identifiant, car sinon l'ensemble des données dupliquées se mélangeait.
Ces nouvelles routines permettent de traiter en boucle les objets du Buffer (copie de donnée) ou récursivement (copie de dossier). Nos CPUs vont enfin pouvoir travailler...

Dans XT4, comme dans la plupart des logiciels, une donnée collée est immédiatement recopiée dans le Buffer afin de permettre plusieurs collages à la suite. C'est cette partie qui a été un peu plus délicate à coder.


Bref, il est maintenant possible de couper, copier et coller des paquets entiers d'évènements "liés" (un évènement répétitifs et ses multiples instances surchargées) de façon transparente d'un dossier à un autre ou dans le même dossier.


Prochaine étape : la même chose via drag-and-drop après une petite pause bien méritée sur le balisage XML des Props.


Sinon, le système de Buffer par liste de pointeurs est facile à manipuler, on peut donc espérer que le passage des différents outils à la multi-sélection (tâche non prioritaire) ne demandera pas trop de rework.

[Denis]

Re,

content d'entendre ca : "une petite pause bien méritée sur le balisage XML des Props" (si c'est bien ce que je crois)

Content aussi de voir que XT4 progresse (sérieux je l'attend grave, marre de bidouiller avec plusieurs pages de Notes ou de Mémoires).
Pense à faire une pause de temps en temps. Comme je dis à mon fils quand il joue sur son PC "1h30 ca suffit, arrête-toi là, sinon tu vas devenir débile....déjà que tu as une tendance..." (c'est ce que je dis à mon afils, hein, pas à toi....)

@+

[Xavier]

...
content d'entendre ca : "une petite pause bien méritée sur le balisage XML des Props" (si c'est bien ce que je crois)
...

Je vais devoir laisser décanter un peu le sujet car ça coince.

J'utilise les Properties des objets pour stocker des constantes et variables en mémoire.
Afin de les distinguer des autres, ces Properties "internes" sont préfixées par un point :

IntProps.png

A l'écriture, ces champs ne sont écrits que si le flag de la console est activé :

Console.png

(Cette écriture des Properties internes est très utile pour le debug,je ne peux plus m'en passer.)
A la lecture d'un fichier XML, ces champs sont toujours ignorés grâce à un filtre.


Le problème est que tout explose sur ces balises <.Truc>, elles ne sont pas compatibles XML.
Donc passer à un balisage des Properties m'obligerait à renommer toutes mes Properties internes. Ca demande donc réflexion, d'autant que le gain en place ne se fera que sur les Properties de plus de 9 caractères, car j'économiserai "Prop" + "=" + "Prop".

Pour les autres ça prendra en fait plus de place :

Code : Tout sélectionner

      <Prop>SaveInternalProps=True</Prop>
      <SaveInternalProps>True</SaveInternalProps>