I'm having a problem with command handlers in Eclipse Luna RCP.
In my E4 application model, I defined some commands and related handlers that must be enabled
only under certain circumstances. For this reason, in my handler POJOs, I implemented
methods annotated with #CanExecute where I check the required conditions.
I also defined menu and toolbar items associated with those commands.
The problem is that my #CanExecute methods aren't properly invoked and, as a consequence,
menu and toolbar items aren't enabled/disabled accordingly.
In particular, for menu items, the #CanExecute methods are only invoked a few times at application startup, but never after that.
For toolbar items, instead, the #CanExecute methods are only invoked when the active context changes (e.g. when changing the active part or opening a new shell).
In Kepler, the behaviour was quite different (and worked as expected):
for menu items, the #CanExecute methods were invoked each time a menu was shown
for toolbar items, there was a timer that invoked the #CanExecute methods every 400ms
Is this a known bug in Luna? Do you know any possible workaround to achieve the expected behaviour?
Thanks!
This is a design change in Eclipse Luna described in bug 427465, also 436755
You can get the toolbar #CanExecute methods run using:
eventBroker.send(UIEvents.REQUEST_ENABLEMENT_UPDATE_TOPIC, UIEvents.ALL_ELEMENT_ID);
'eventBroker' is the IEventBroker.
Related
JMSToolBox is an eclipse-rcp v4.5.2 based application.
I tried to upgraded to eclipse v4.6.0 but found a problem with popups menu as follows:
A part is defined in the e4 model as a Part Descriptor (PD). A popup menu is defined inside that PD
On a certain action, the PD descriptor is instanciated and the part is added and displayed in a Part Stack. The body of this part is a TabFolder with multiple tabs corresponding to a JMS Q browsed. Each tab body is basically composed of a TableViewer/Table to display JMS messages.
Each time a new tab is created, a new TableViewer/Table is created and the popupmenu is registered on the Table of the TableViewer with the following line of code:
menuService.registerContextMenu(table,<id of the popup menu in the part>);
This works perfectly with eclipse v4.5.2 (Mars) but not with v4.6.0 (Neon) !
With neon, the popup is working only for the first tab: the context menu is visible and #CanExecute methods associated to the handlers/commands of the menu items are called . For subsequent tabs created, no popup is displayed and #CanExecute methods for the menu items are not called
If I register a different menu with a different Id (previously added to the PD) for each tab, it works! So I suspect this may be due to the fact that a menu with the same element id is added to multiple TableViever/Table even if it is coming from a different instance of a PD...
Is it a bug in neon? a regression? or do I benefit of a bug in mars that makes the application is working Ok with this version?
For now I have to downgrade (or not upgrade) to eclipse v4.5.2..
For reference, I pushed some code to correct the problem. It will be in eclipse v4.6.1+ bug #496695
I have a wizard that should be launched in different ways: from the menu (org.eclipse.ui.menus + org.eclipse.ui.actionSets) and from the New context menu. For the later I used the extension org.eclipse.ui.newWizards to add the wizard into the context menu. So far, so good...
For some reasons I had to subclass the wizard dialog (changed the finish button text in the dialog). If the wizard is launched from the menu, the action (defined in org.eclipse.ui.actionSets) creates and opens this special wizard dialog and everything is fine.
If the wizard is launched from the context menu (org.eclipse.ui.newWizards), the internal class NewWizardShortcutAction is taken that creates the "normal" wizard dialog (and not my subclass) to open the wizard.
Is there any way to modify the implementation of the extension point that only my subclassed wizard dialog is used?
By default the command uses org.eclipse.ui.internal.handlers.WizardHandler.New to launch the new wizard dialog, and that's the default handler provided to the command.
It would be possible to register a different handler at the Workbench Window level, and that would override the default handler while a Workbench Window was active. It could be done in the plugin.xml or in your application ActionBarAdvisor:
IHandlerService hs = (IHandlerService) window.getService(IHandlerService.class);
hs.activateHandler(IWorkbenchCommandConstants.FILE_NEW, new MyNewHandler());
But you would have to implement whatever support was needed in the handler to launch the wizard with the correct selection.
I'm also trying to do the same. The way I will be doing this is to register my own custom action, by removing the old action, will post back the solution if it works !
Update: I ended up using a different approach. If you see the run method in NewWizardShortcutAction, it is just calling init, creating the WizardDialog and opening it. So in my override of the init in MyWizard class, I just used my own MyWizardDialog extending from WizardDialog and opened it. Subsequently, I need to make that the run function will not re-open the WizardDialog, so I track that using a boolean in MyWizard that will disallow getting any pages so that the WizardDialog in the run method will not be displayed.
This is a hacky solution but works !
In our project at work, they have written one plug-in for eclipse helios. They have used the
objectContribution for adding the popups and written respective action classes for them.
I am trying to add the shortcut key for one of the popup menu item in project explorer.
But I read here http://www.eclipse.org/forums/index.php/mv/tree/172398/#page_top that there is no way to call key bindings from objectContribution and need to migrate it to handlers/commands.
Is there any other way to bind keys to popups instead of migrate them to handlers?
Thanks in advance!!
No, objectContributions cannot accept keybindings. From legacy action extension points, only actionSets accept keybindings correctly.
The other option available (as mentioned) is to provide a handler for the command you want. The handler won't interfere with the objectContribution behaviour (the objectContribution action delegate class will still be called directly from the menu item, the handler would be called when using a keybinding).
PW
I am using eclipse 3.6. I created one sample plugin application. It is neither a eclipse rcp nor workbench. Now when I run the eclipse I want that plugin also to be loaded. But I dont want to use IStartUp. Because what I have found out is
IStartup will be called after the workbench is loaded. I want to refresh some menu. So Is there any way to activate my plugin while the eclipse loaded?
I tried to use Bundle Activation policy. But that is also not activating my Activator class. I just put one System.out. println("Inside start()"). So that is not called. Now can I make it activate my activator?
EDIT:
what my exact requirement is, I have created one workbench application.It is not eclipse rcp application. Now I want to remove the following menu and menu items from the eclipse before the eclipe is loaded.
1. File Menu
2.) Search Menu
3.)Run Menu
4.)Help->search,Dynamic Help,Key assist,Tips and trick,Report Bug,Cheat Sheet.
These menus are inbuilt menu of eclipse. So that is the reason I have to do in this way.
So I already implemented by using startup extension point. But the early startup is called after the eclipse is started.So I need to do some refreshment on the workbench.Then only the menu item will get removed.So I thought I need startup extension point will not satisfy my requirement as it doesnot refresh the workbench.I need to activate the my plugin and refresh the workbench before it is loaded.
Thanks
Bhanu
You can set the needed start level for your plugin using touch point instruction.
You are just a plugin that expects to run in the Eclipse IDE?
Then the answer is, you cannot do what you want.
If you start before the workbench has finished initializing, most of the services that could be used won't work: The workbench itself, menu service, command service, etc.
For most plugins in eclipse, the plugin.xml should be used to add menus, views, editors, etc to eclipse. When necessary, the framework will instantiate them.
org.eclipse.ui.IStartup is available and as you mentioned it will be called after the workbench has been initialized, but before any windows have been shown. It's not to be used lightly, and not by plugins contributing to the UI as it allows all extension from that plugin to be loaded.
EDIT:
If you are an RCP app, you control the main menu. As an RCP app, you have access to the ActionBarAdvisor, WorkbenchAdvisor, WorkbenchWindowAdvisor, which all have lifecycle methods.
If you are an an eclipse plugin, you can add to the main menu ... you cannot easily remove from the main menu. This is by design. Start levels and org.eclipse.ui.startup are 2 mechanisms that won't do what you want.
You still need to answer these questions:
There might still be a way. The crux of your problem is: "I want to refresh some menu"
What kind of menu (popup, main menu,
compound list of menu items in a
menu, etc)?
Where is the menu contribution coming from?
Which specific menu item is it?
Please edit your question (do not comment) and include the information from the above 3 questions, please.
Our Eclipse RCP application was originally built in the 3.1/3.2 era and was running on 3.2 until we switched to 3.6 recently. Its IApplication runs via PlatformUI.createAndRunWorkbench(...). The WorkbenchAdvisor we pass to that function overridescreateWorkbenchWindowAdvisor(...) to return a WorkbenchWindowAdvisor whose createActionBarAdvisor(...) returns an ActionBarAdvisor.
This ActionBarAdvisor's makeActions(...) creates and register()s a bunch of org.eclipse.jface.action.Actions, many of which do things like setAccelerator(SWT.CTRL | 'O'); in their constructors. The Actions are subsequently installed in the ActionBarAdvisor's fillMenuBar(...) and fillCoolBar(...) methods.
The problem we are having (now that we are on Eclipse RCP 3.6) is that these accelerators don't seem to be active until their menus are shown (even if no action is taken besides closing the menu again).
We see a relevant bug but are having some difficulty understanding how to apply its remedy to our situation. We recognize that instead of Actions we "ought" to be using commands, handlers, and key bindings. But we're hoping we don't have to go down that path just yet.
How can we make our accelerators "live" as soon as the application starts up?
If you don't choose to use o.e.ui.bindings extension point, then there isn't a better way. You should only force update the menuManager yourself as you have done in your answer.
As #Prakash mentioned, if you want to keep down that path in your RCP app you must render all of the main menus to see your accelerators.
There is a partial upgrade path that will get you on the right track to commands without forcing a complete switch over right away. For each action in your menu, define a command with an id and define a binding to the shortcut you want in your plugin.xml. Then, when you create the action in your ActionBarAdvisor, don't set the accelerator. Set the IAction.setActionDefinitionId(*) to the command id, can call register(action);
Then you no longer need to use menuManager.updateAll(true) to eagerly render all of your main menu.
After hunting around and experimenting a bit trying to apply the advice from the bug, we added the following to our WorkbenchWindowAdvisor, which seems to have done the trick:
#Override
public void postWindowCreate() {
getWindowConfigurer().getActionBarConfigurer().getMenuManager().updateAll(true);
}
We have no idea how well this fits with the Workbench's design expectations; there could be a better way.