[RCP 3.5] Etat d'un toggle button au démarrage de l'application

Bonjour,

j'ai une vue (en fait plusieurs fonctionnent sur ce principe) dont l'affichage est controllé par un bouton de toolbar de type toggle : quand la vue est affichée (créée) le toggle est checked, quand elle est cachée (fermée) , le bouton n'est pas checked.

Le handler implémente IElementUpdater et j'utilise un paramètre de la commande pour déterminer la vue associée.

Tout fonctionne bien sauf au démarrage.
Alors que mes vues sont ouvertes au démarrage, tous mes boutons associés sont not checked.

En débugguant je vois que la méthode updateElement n'est pas appelée parce que le handler est null dans HandlerProxy.

D'après le code, le handler est construit plus tard. Et c'est le cas dès que j'actionne l'un des boutons, tous les autres se mettent à jour.

Mais je voudrais que tous les boutons reflètent l'état de mes vues au démarrage. Comment forcer l'instanciation des handlers ? Ou comment changer l'état de l'action de toolbar avant que le handler ne soit créé, au moment ou ma vue se créée ?

Je ne sais pas si c'est la bonne méthode (je la trouve un peu pourrie personnellement), mais voilà que ce que j'ai fait pour que ça fonctionne :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

public static void updateState(IToggleView view, boolean state) { storeState(view, state); ICommandService commandService = CommandUtil.getCommandService(); Map<Object,Object> filter = new HashMap<Object, Object>(); filter.put(VIEW_ID_PARAMETER, getViewId(view)); for(String commandId : getCommandIds() ) { Command command = commandService.getCommand(commandId); State toggleState = command.getState(TOGGLE_STATE_ID); if (toggleState==null ) { // au cas ou défaut de configuration toggleState = new ToggleState(); toggleState.setValue(state); command.addState(TOGGLE_STATE_ID,toggleState); } else { toggleState.setValue(state); } commandService.refreshElements(commandId, filter); }

---

ou TOGGLE_STATE_ID contient bien sûr l'id de state que j'ai mis sur ma commande

EDIT : mince, c'était presque ça : le filtre n'étant pas applicable à la commande, ça modifie toutes les instances de la commande et pas seulement celle associée à la vue en cours de traitement :( trouve pas comment récupérer les callbacks pour filtrer !!!

Pour l'instant toujours pas de solution. Je commence à croire que ce n'est pas prévu : du coup, il faut que l'utilisateur clique sur le bouton pour que son état soit cohérent avec l'état de la vue que le bouton affiche ou cache. En cas de fermeture le bouton change bien d'état (parce que je peux le faire), mais pas l'instance de IElementReference associée, du coup la preférence n'est pas mise à jour, et à l'ouverture suivante, le bouton n'est pas dans un état cohérent :( C'est quand même bien naze.

Salut,

J'ai un peu de mal à comprendre le fonctionnement de ton bouton.
Déjà, où est -il situé? Dans la toolbar globale ou bien dans celle de chaque vue?
Est-ce que l'état du bouton est lié à l'état d'une vue ou bien à l'état d'un couple Command / Handler?


Voilà, à+
Gueritarish

Salut,

il s'agit de bouton dans la toolbar globale. Mais dans l'absolu, il pourrait au final s'agir de n'importe quel type de contribution, de menu, ou de menu contextuel, ou d'une viewActions d'une autre vue, ou d'un éditeur, peu importe. Mais déjà, si je pouvais le faire fonctionner pour les boutons de toolbar globale, ce serait suffisant.

En fait, j'ai fait une extension pour gérer une vue particulière paramétrable. Il peut y avoir plusieurs instances de types différents, avec des paramétrages différents.

Dans ces paramètres, on peut indiquer si une vue est du type "toggle", type pour lequel je souhaite pouvoir indiquer un bouton "Afficher/Cacher", et je voudrais que son état checked reflète l'état affiché de ma vue.

Il s'agit d'un produit, auquel des configurateurs peuvent ajouter des nouvelles vues par cette extension : si la vue est de type toggle, il leur suffit d'ajouter des contributions (s'ils le souhaitent) pour afficher/cacher cette vue. Je fourni une implémentation de handler qu'ils associent à une commande, qu'ils associent à leur contribution.

Et donc je voulais que le handler gère automatiquement l'état checked du bouton en fonction de l'affichage courant de cette vue (qui peut être modifié par ce bouton, mais aussi par un autre contribution, voir un appel de la commande direct dans le code, ou le bouton de fermeture de la vue, ou autre...). Pour toutes ces types d'actions j'ai un système d'écouteurs, mais à l'ouverture de l'application, je n'ai pas trouvé de moyen de forcer l'état en fonction de l'état de la vue à l'ouverture (qui peut éventuellement changer par la configuration (ouvert par défaut, ou pas) ou par les préférences (fermée lors de la précédente session) : donc je ne voulais pas avoir à faire confiance dans l'état du bouton, mais le forcer avec un état déduit de la vue associée.


Voilà un screen shot, avec 2 vues paramétrées, et 2 boutons de type toggle associés :

http://www.developpez.net/forums/att...1&d=1381839595

Ok, c'est plus clair. Mais vachement moins simple à mettre en oeuvre...

Comme ton but est de faire refléter état du bouton et vues réellement ouvertes (et que je dirais que tu es dans un RCP), tu peux utiliser la méthode postWindowOpen() de ton WorkbenchWindowAdvisor.

Si t'es pas dans un RCP, ça va être plus galère puisqu'il s'agit d'un traitement qu'il te faut faire après l'initialisation du workbench.

Voilà, à+
Gueritarish

Citation:

---

Envoyé par Gueritarish

Ok, c'est plus clair. Mais vachement moins simple à mettre en oeuvre...

Comme ton but est de faire refléter état du bouton et vues réellement ouvertes (et que je dirais que tu es dans un RCP), tu peux utiliser la méthode postWindowOpen() de ton WorkbenchWindowAdvisor.

Si t'es pas dans un RCP, ça va être plus galère puisqu'il s'agit d'un traitement qu'il te faut faire après l'initialisation du workbench.

Voilà, à+
Gueritarish

---

Oui, effectivement, je n'avais pas pensé à faire ça dans le postWindowOpen, mais mon problème est surtout comment retrouver les contributions à mettre à jour. Comme j'ai fait une extension perso sous forme de listener déclenché dans le postWindowOpen, je peux effectivement facilement ajouter un callback indépendant dans mon plugin qui sera sollicité sur le postWindowOpen et qui aura la visibilité nécessaire sur mes interfaces et classes d'implémentation, et qui pourra connaitre tous les id de vues à traiter.

Ensuite, je pourrais effectivement parcourir toutes les contributions (en particulier de la toolbar globale), mais je ne suis pas sûr que je puisse plus facilement trouver celle qui est censé lancer ma commande pour une vue en particulier (dans le code précédemment posté, on voit que je récupère les commandes qui m'intéressent en cherchant celle qui ont un paramètre dont je connais l'identifiant, et dont la valeur est l'id de la vue).
Je suppose que je peux récupérer facilement de la même manière le CommandContributionitem, mais à partir de là, je vois pas trop comment déterminer les valeurs de paramètres que la commande va utiliser, et donc connaitre l'identifiant de la vue dont je dois connaitre l'état que je dois appliquer au CommandContributionItem...


Pour préciser, mon extension s'attache à la vue par l'id de la vue (définie dans l'extension org.eclipse.ui.views). J'ai mis un paramètre sur la commande pour indiquer l'id de la vue, et refreshElements me permet de filtrer les callbacks, mais pas moyen de faire un state.setValue(...) et comme le handler est instancié en lazy, le refreshElements n'a pas d'action sur lui au démarrage, puisqu'il n'existe pas à ce moment) : je n'ai que la possibilité d'inverser l'état (via la classe HandlerUtil), mais ça agit sur une commande, par sur un callback particulier (celui dont le paramètre en question a pour valeur l'id de ma vue), et en plus ça ne permet que d'inverser l'état, ni de lire sa valeur, ni de la modifier.

Donc dans le postWindowOpen, comme dans mon gestionnaire actuel, le problème est surtout de retrouver les items qui lancent une commande avec une valeur de paramètre particulière.

Autre solution que j'ai pensé, trouver un moyen de forcer le HandlerProxy à créer le handler. Ce serait un peu contourner la conception de base de Eclipse RCP, mais s'il faut faire ça, tant pis à la limite. Cependant à part forcer l'exécution de la commande, donc en l’occurrence, fermer une vue ouverte ou ouvrir une vue fermée, je vois pas trop comment, sans parler du fait qu'après il faut que je rétablisse l'état normal, donc on va voir flasher mes vues...pas terrible... sans parler de tous les mécanismes associés : pour peu que ma vue soit associée à une requête longue avec l'option remplissage au démarrage, et on se paye au démarrage éventuellement 2 fois la requête, juste pour mettre un bouton à jour...je suis pas chaud là ;)
D'un autre coté, je pourrais pas le faire non plus, vu que je n'ai pas plus de moyen d'avoir une référence sur l'instance de HandlerProxy, que j'ai de moyen d'obtenir la référence de callback :(

En grops, il me faudrait une méthode du type refreshElements qui peut me permettre d'initialiser un état en passant le même type de filtre.

Je pourrais aussi ne travailler avec les ids de commandes, en faisant une commande différente par vue, mais en dehors du fait que ça ajoute des contraintes au niveau de la façon de configurer le produit (et tout ajout de contrainte induit des défauts de configuration avec les zozos qui font les configurations habituellement, malgré des tonnes de doc ;) - c'est un peu la raison qui me fait chercher à faire des trucs bien chiadés pour laisser le moins de latitude possible aux configurateurs, sans toutefois fermer des options de contribution par extension, ce qui pourrait gêner l'adaptation du produit à un client particulier), les essais que j'ai fait n'ont pas été plus fructueux, comme si le changement d'état sur la commande n'était pas transmis aux UIElements, mais avec un refreshElement : je me demande si l'initialisation de l'état n'est pas faite beaucoup plus tard, et donc "remplace" mon traitement. Dans ce cas ta solution de le faire au postwindowOpen devrait marcher. Je vais tenter ça...