J’ai enfin réussi à me sortir du problème où je n’arrivais pas à faire fonctionner la VisualPropertyPage lorsqu’il y avait plusieurs images chargées dans l’application. Dans le détail (mais pas trop), quand un utilisateur ouvrait une image et sélectionnait un outil (dans le cas qui m’intéresse pour l’instant est le QuickExtract [pouvoir sélectionner plusieurs fragments d’une image et les sauvegarder chacun avec un nom de fichier séquentiel]) et entrait les paramètres dans la VisualPropertyPage, qu’il ouvrait une deuxième image et entrait d’autres paramètres, le fait de retourner à la première image faisait perdre les paramètres sélectionnés grrrrr!

Je suis resté coincé longtemps tout simplement parce qu’une gestion d’événement, en l’occurrence le changement de focus d’une image vers une autre, n’était pas pris en charge par la bonne classe, c’est-à-dire que j’arrivais bien à lancer un événement “hé! l’utilisateur a mis le focus sur cette image-ci”  mais le code qui répondait et devait mettre à jour les infos dans la VisualPropertyPage n’était pas à la bonne place, ce qui occasionnait un paquet d’embrouilles que je tentais de résoudre et, finalement, en composant le diagramme de séquence UML pour mieux visualiser le tout, la solution toute simple m’a sauté aux yeux.

Les paramètres entrés dans la VisualPropertyPage sont passés aux propriétés de l’instance de l’outil ou de l’effet en cours. Je pouvais, pour les récupérer par la suite, simplement interroger ces propriétés, mais c’était devoir réinterroger les attributs de ces propriétés (ceux qui servent à construire la série de contrôles visuels de la VisualPropertyPage) et donc utiliser la réflexion (un processus très flexible et polyvalent mais plus lent). J’ai plutôt opté pour stocker les paramètres dans une collection séparée, pensant m’éviter l’utilisation abusive de la réflexion… un peu inutilement puisque de toute façon, reconstruire les contrôles de la VisualPropertyPage à chaque changement de focus demande d’interroger les attributs. Même si pour l’instant l’ensemble fonctionne, ça laisse beaucoup de place à améliorations.

Dans la vidéo ci-dessous on voit l’ouverture de deux images, l’entrée de paramètres différents pour chacune d’elles (sauvegarde des sélections dans des répertoires différents et attribution d’un préfixe unique pour chacune). On voit aussi qu’on peut passer d’une image à l’autre et les paramètres “suivent”.

Prochaine étape: profiter de cet outil que je viens de créer et, enfin, produire les centaines de fragments, d’extraits pour créer d’autres images. Probablement que si je m’étais tout simplement attelé à Photoshop et copié/sauvegardé les sélections j’aurais terminé en moins de temps que ce qui m’en a pris pour coder cette fonctionnalité. Il y de ces plaisirs de faire qui tombent dans l’irrationnel 🙂

Entre temps, la nouvelle version 0.0.5 est disponible sur GitHub 🙂

* * *

I finally managed to find a solution to the problem where I could not get the VisualPropertyPage running when there were several images loaded in the application. In detail (but not too much), when a user opened an image and selected a tool (in the case that interests me for now is the QuickExtract [select multiple fragments of an image and save each with a sequential file name]) and entered the parameters in the VisualPropertyPage, when another image is loaded and new parameters are entered, returning to the first image looses its parameter values grrrrr!

I was stuck for a long time simply because an event handler, in this case the change of focus from one image to another, was not supported by the right class, that is even if I had managed to launch an event “hey, the user has focused on this image” but the code that handled it and was responsible to update the information in the VisualPropertyPage was not in the right place, which caused the need to over-manage the code with multiple ambiguous states I was struggling to solve and finally, by composing the UML sequence diagram to visualize the whole thing, the simple solution revealed itself to me.

Parameters entered in the VisualPropertyPage are passed to the properties of the instance of the current tool or effect. In order to retrieve the values later, I could have simply queried these properties, but it was necessary to re-interrogate the attributes of these properties (those used to build the series of visual controls of the VisualPropertyPage) and therefore use reflection (a very flexible and versatile functionality but slower). I have instead opted to store the parameter values in a separate collection, thinking I could avoid to use reflection… a bit unnecessarily since, anyway, rebuilding the controls of the VisualPropertyPage at each change of focus request does require to query the attributes. Even if for now the whole thing works, there remains a lot of room for improvement.

In the video above we can see the opening of two images, the entry of different parameter values for each of them (saving selections in different directories and assigning a unique prefix for each). We also see that we can go from one image to another and the parameters are appropriately updated in the VisualPropertyPage.

Next step: enjoy this tool of mine and finally extract hundreds of image fragments, and save them to create new images. Probably if I had just used Photoshop and copied/saved the selections I would have finished in less time than what took me to code this feature. This is a case where working on something for the mere pleasure of it does fall into the irrational 🙂

Meanwhile, the new version 0.0.5 is available on GitHub 🙂