Community
Participate
Working Groups
I have a class implementing IHandler and IElementUpdater, which is bound to 2 command entries which are contributed using the extension point org.eclipse.ui.menus. The command entries have radio style and are located within a popup menu. Now, the very first time I right-click an element in my editor, the context menu shows up, but none of the MenuEntries is selected. After clicking one of the entries, the correct entry is selected (correct with respect to my implementation of IElementUpdater.updateElement()), not only for this element, but also for all other elements I right-click later. I've set a conditional breakpoint in method CommandService.registerElement(IElementReference) and tracked this down to the following: The method is called when the context menu is created, but at this time, the proxy handler's handler attribute (i.e., the instance of my IHandler) is still null. Therefore, the call to command.getHandler().updateElement(*) does not result in any action - the initialization does not happen. A simple workaround was to add code to my plug-ins Activator.start(*) method. I create an UIJob which gets my command from the commandservice and then executes it (with no effect, though). This forces the ProxyHandler to instantiate my handler. The context menu items are then correctly initialized. If anybody knows a more elegant way to "initialize" my Command, please let me know :-)
(In reply to comment #0) > If anybody knows a more elegant way to "initialize" my Command, please let me > know :-) > Asking for the Enabled-State of the command should also work (IMHO better than executing the command), see http://wiki.eclipse.org/Menu_Contributions/Radio_Button_Command#Initializing_the_Handler In my Usecase I additionally had to define an empty org.eclipse.ui.startup Extension that forces the bundle startup for initializing the handler.
(In reply to comment #1) > > If anybody knows a more elegant way to "initialize" my Command, please let me > > know :-) > > > > Asking for the Enabled-State of the command should also work (IMHO better than > executing the command), see > http://wiki.eclipse.org/Menu_Contributions/Radio_Button_Command#Initializing_the_Handler Thanks for pointing that out - in fact, somebody else (was it Paul?) already gave me the hint to check if the commands are enabled, and I wrote the wiki entry you linked to :-) I should have provided that link here myself as a reference, though...
We need to consider how to integrate checked state or radio state into org.eclipse.ui.menus. Commands has a partially implemented mechanism that involves subclasses of org.eclipse.core.commands.State which can be used to tell the handler what state a command believe it is in. It also would save/restore that state to the command over session restarts. Would it be feasible to initialize CommandContributionItems from that state? Is it a good idea? Maybe we could also provide a "PreferenceState" object so that the command state would really be backed by the preference store (I'm not sure how useful this would be). PW
Created attachment 127633 [details] Patch 01 for toggle state Attached is the patch & tests that handles the toggle state. Still working on the radio state
Created attachment 127695 [details] toggle state v02 Looks good. I've made some minor mods (added a constant, etc). What happens when you add a toggle command to the toolbar twice (i.e. 2 separate menu contributions for the same command)? When you click on one, both should toggle. PW
(In reply to comment #5) > Created an attachment (id=127695) [details] > toggle state v02 Released to HEAD >20090305 PW
(In reply to comment #5) > What happens when you add a toggle command to the toolbar twice (i.e. 2 > separate menu contributions for the same command)? When you click on one, both > should toggle. Yes. it works that way.
Created attachment 127790 [details] Radio state patch 01 Patch for Radio state.
(In reply to comment #8) > Created an attachment (id=127790) [details] > Radio state patch 01 > Comments: The API of your RadioState is fine, but we should probably implement it by extending TextState and use the same pattern as RegistryToggleState ... support persist and default in the IExecutableExtension part. I wish we could have called it RegistryRadioState but that's already taken :-) Change call isInUpdatedRadioState(*) something like matchesRadioState(event) In HandlerProxy we don't need private IStateListener radioStateListener, as AbstractHandlerWithState adds HandlerProxy as the listener to every State on the Command, so you should implement what you want in the handleStateChange we already have. Also, your test has values="org.eclipse.bugs.commandstate.handlers.RadioStateParameterValues"> in your plugin.xml ... that class doesn't exist. PW
Created attachment 127836 [details] Radio State patch v02 (In reply to comment #9) > The API of your RadioState is fine, but we should probably implement it by > extending TextState and use the same pattern as RegistryToggleState ... support > persist and default in the IExecutableExtension part. I wish we could have > called it RegistryRadioState but that's already taken :-) Problem with TextState is that when it loads from the preference and there is no preference exists, it sets the value to "". This will overwrite the value from the plugin.xml. Further, the load method is frozen to final, so it cannot be overridden. So which means, if we subclass from TextState, then we cannot do initialization from plugin.xml at all > Change call isInUpdatedRadioState(*) something like matchesRadioState(event) Done. > In HandlerProxy we don't need private IStateListener radioStateListener, as > AbstractHandlerWithState adds HandlerProxy as the listener to every State on > the Command, so you should implement what you want in the handleStateChange we > already have. Done. > Also, your test has > values="org.eclipse.bugs.commandstate.handlers.RadioStateParameterValues"> in > your plugin.xml ... that class doesn't exist. Sorry for that. Copy paste error. Deleted it now.
(In reply to comment #10) > Created an attachment (id=127836) [details] > Radio State patch v02 > > Problem with TextState is that when it loads from the preference and there > is no preference exists, it sets the value to "". This will overwrite the value > from the plugin.xml. Further, the load method is frozen to final, so it cannot > be overridden. So which means, if we subclass from TextState, then we cannot do > initialization from plugin.xml at all While it's up to you, you could just remove the final and add javadoc + @nooverride to the method But I'm not really that interested, and I think that's something we could change after M6 (assuming we can convince the PMC that final == @nooverride) PW
(In reply to comment #10) > Created an attachment (id=127836) [details] > Radio State patch v02 Released to HEAD with minor mods and some javadocs >20090306 PW
Verified in I20090310-0100
