Mar 13/03/2012 - Actualités


09:05

Prototype de la fenêtre d'export :

Joli !! Sérieux, première version XT a donner envie pour son look !

DMo a écrit :Joli !! Sérieux, première version XT a donner envie pour son look !

Merci.

Oui, je réduis l'usage des GroupBoxes, ça allège les fenêtres (et la traduction).

Et je ne suis plus bloqué par les icônes maintenant que je pioche des Bitmaps ici et les retravaille sous IcoFX avant de faire un save final sous Paint.

Ouh pinaise, y'a même une scrollbar
Le prototype donne un bon aperçu déjà...

14:25

Sous XT3, l'ajout d'un nouvel outil nécessitait la mise à jour de plus d'une dizaine de méthodes disséminées dans le Noyau, le Moteur, la Barre et même les Services. En plus de l'icône sur la Barre, il fallait rajouter du code pour gérer les opérations de sauvegarde, traduction ou fermetures déclenchées globalement au niveau de l'application, plus divers compteurs et bien sûr les options qui étaient toutes stockées au niveau du Noyau...

L'objectif pour XT4 était de minimiser au maximum le besoin de coder dans diverses unités pour chaque nouvel outil, afin d'encourager autant que possible l'apparition de nouveaux outils. Ce principe d'implémentation "MultiTool" passe par la généralisation des actions programmées pour boucler sur des listes, les outils de l'application n'étant plus considérés comme des portions de programme mais comme des objets. Et c'est ici qu'interviennent les XDs, dont je loue d'ailleurs quotidiennement la puissance et la souplesse :

• A partir de l'unique variable XD_Kernel (l'XD patriarche), il ne reste qu'à boucler sur ses Children pour récupérer les XDs de chaque unité.
• Il faut ensuite filtrer les XDs sans fenêtre (tel le module de cryptage) et les XDs sans données (tel l'outil Sécurité), grâce à divers Properties des XDs.
• La dernière amélioration est un lien à double sens entre l'arbre des XDs et l'arbre des dossiers, dont le besoin est apparu pour la fonction Export.

Il existait déjà un lien à double sens entre l'XD et sa fenêtre, désormais la totalité des objets manipulés sont liés et accessibles par navigation :

• Les XDs qui stockent les constantes et les variables internes, ainsi que les options de l'utilisateur,
• Les dossiers et données de l'utilisateur,
• Les objets graphiques des fenêtres.

XT4 a désormais la meilleure base qu'il était possible d'imaginer, le passage à l'objet a longtemps été repoussé mais aujourd'hui que c'est fait, je remercie DMo pour son constant encouragement à me faire passer au full object.


Exemple concret avec le changement de langue dans les Options et la traduction en temps réel de toutes les fenêtres ouvertes :

XT3:

• La fenêtre Options vérifie que la vingtaine de fenêtres possibles est ouverte, et apelle la méthode Form_Translate de chaque fenêtre ouverte.
• Il fallait penser à rajouter une ligne pour chaque nouvelle fenêtre.

XT4:

• La fenêtre Options appelle un service qui boucle sur les Children de XD_Kernel, ignore ceux qui n'ont pas de fenêtre, ceux dont la fenêtre n'est pas ouverte, enfin récupère le Handle de la fenêtre (stocké sur l'XD sous forme de Pointeur converti en Integer) et appelle sa méthode Form_Translate.
• Rien à coder pour les nouveaux outils.

BV pour FindIcon et icoFX. De rien pour mon insistance, c'est dans ma nature d'être chiant, et je n'en suis pas tjrs remercié

17:05

Utiliser un répertoire en lecture seule pour essayer de comprendre pourquoi le TSaveDialog refuse de s'ouvrir pré-positionné dans un certain répertoire est une très mauvaise idée.

18:05

Le Gestionnaire fait une copie de l'arbre des données quand il s'ouvre. Le besoin initial était de pouvoir parser les données afin de gérer les ChexBoxes selon un algorithme simple (voir paragraphe suivant), ce qui aurait été possible avec un TreeView mais ne l'est pas avec un ListView. La totalité des données est donc recopiée dans un nouvel arbre (détruit à la fermeture de l'outil) et ce sont ces données qui sont manipulées par l'outil. Un effet de bord bienvenu est l'indépendance de l'outil par rapport aux autres.

La gestion des CheckBoxes devrait à priori fonctionner selon ces deux régles :

• Sélection manuelle d'un dossier : sélection automatique de tous les dossiers ascendants et descendants.
• Dé-sélection manuelle d'un dossier : dé-sélection automatique de tous les dossiers descendants.

(Et pour cela j'ai besoin d'un arbre car je vais récursiver.)

19:25


Wooot, ça marche super bien !

Avant sélection de l'outil Contacts : Après :

Idéalement il te faudrait des checkbox à 3 états : le troisième état signifiant "partiel": pour ceux dont une partie du sous-arbre est coché..

DMo a écrit :Idéalement il te faudrait des checkbox à 3 états : le troisième état signifiant "partiel": pour ceux dont une partie du sous-arbre est coché..

Oui la plupart des écrans similaires utilisent trois états, mais Delphi 5 n'en propose pas. Ce qui je pense n'est pas super grave car l'arbre reste toujours ouvert, donc c'est facile de voir ce qu'on a sélectionné.

Le TopItem sera renommé en Racine ou Données, car je préfère le conservé coché même pour un export partiel (derrière, il faut quand même exporter la racine de l'arbre), donc Tous les dossiers ne va pas trop.

En sélectionnant un type d'export CSV, il faudra dissimuler cette racine, car ça ne fonctionnera que pour un outil à la fois, et décrémenter toutes les indentations.

Je crois me souvenir qu'il existe une option pour cacher le noeud racine (ou pour ne pas en avoir un unique...)

DMo a écrit :Je crois me souvenir qu'il existe une option pour cacher le noeud racine (ou pour ne pas en avoir un unique...)

Oui en effet, mais ça c'est pour du TreeView. Là je suis en ListView, donc je fais ce que je veux, chaque ligne est une bête ligne de texte dont l'indentation fait croire à un arbre.

(Item.Indent := Item.Parent.Indent + 1;)