Community
Participate
Working Groups
When launching an RCP application from PDE icons/actions are lost. RC6 loses a general action from the toolbar even thou' it appears in the main menu. The action is added to the toolbar from the plugin manifest and is hooked in as follows using the ToolBarContributionItem. protected void fillCoolBar(ICoolBarManager cbManager) { cbManager.add(new GroupMarker("group.file")); { // File Group IToolBarManager fileToolBar = new ToolBarManager(cbManager.getStyle()); fileToolBar.add(new Separator(IWorkbenchActionConstants.NEW_GROUP)); fileToolBar.add(new GroupMarker(IWorkbenchActionConstants.OPEN_EXT)); fileToolBar.add(new Separator(IWorkbenchActionConstants.MB_ADDITIONS)); cbManager.add(new ToolBarContributionItem(fileToolBar,IWorkbenchActionConstants.TOOLBAR_FILE)); } cbManager.add(new GroupMarker(IWorkbenchActionConstants.MB_ADDITIONS)); cbManager.add(new GroupMarker(IWorkbenchActionConstants.GROUP_EDITOR)); } RC7 loses the above as well as the "run garbage collection" icon on the bottom right of the workbench window. The two mentioned problems work correctly in the Eclipse 3.1.2 final release.
Martin, the "run garbage collection" was turnd off for release (we use it but most of our clients don't really want it). If you want it back ou can find it under "Window > Preferences > General > Show Heap Staus". Could you be more specific as to the other action that is lost (what menu item is i?)
Created attachment 44999 [details] Make ToolBarContributionItem implements IToolBarContributionItem The same problem occurs when contributing actions from one action set to another via plugin.xml If org.eclipse.jface.action.ToolBarContributionItem is changed to implement IToolBarContributionItem expected behavior as pre-RC6 is restored. PluginActionSetBuilder.contributeAdjunctCoolbarAction(ActionDescriptor ad, ActionSetActionBars bars) { ... // create a coolitem for the toolbar id if it does not yet exist IToolBarManager toolBarManager = bars.getToolBarManager(toolBarId); ... } ActionSetActionBars.getToolBarManager(String actionId) { ... >> Condition fails if cbItem is instance of ToolBarContributionItem if (cbItem instanceof IToolBarContributionItem) { ... } else { >> This should not execute, but it does in case of adjunct type >> resulting in creation of second contribution with the same toolBarId coolItemToolBarMgr = actionBarConfigurer.createToolBarManager(); // If this is not an adjunct type then create a tool bar // contribution item // we don't create one for an adjunct type because another action // set action bars contains one IContributionItem toolBarContributionItem = actionBarConfigurer .createToolBarContributionItem(coolItemToolBarMgr, toolBarId); } ... }
I believe Kostadin's patch is correct and will fix the problem. However, I would have expected the action set action(s) to appear in their own toolbar when it failed to match the specified toolbar (due to the instanceof check failing), but it does not. So there seems to be another problem here in the processing of "adjunct" action set actions (those that add to a toolbar other than their own). The workaround for the first problem is to use IActionBarConfigurer2.createToolBarManager and createToolBarContributionItem For example, I modified the browser example to do: protected void fillCoolBar(ICoolBarManager coolBar) { IActionBarConfigurer2 cfg = (IActionBarConfigurer2) getActionBarConfigurer(); IToolBarManager toolBar = cfg.createToolBarManager(); coolBar.add(cfg.createToolBarContributionItem(toolBar, "standard")); // add actions to toolBar as before } and added an action set that contributes an action to the "standard" toolbar. It works when using the IActionBarConfigurer2 factory methods, but not when using ToolBarManager / ToolBarContributionItem directly.
I think this should be a 3.2.1 candidate.
Created attachment 45028 [details] Modified browser example showing the workaround This is a modification of the browser example to use the IActionBarConfigurer2 factory methods to create the hardwired "standard" toolbar, with an action set adding an action to that toolbar.
It turns out that Konstadin's fix also fixes up the second problem mentioned in comment 3. If the action set action's toolbar path is changed to "standard2/additions" instead of "standard/additions" the action still shows up, but in its own toolbar.
Applied the patch and committed (in the 3.3 stream) in >20060623. I'll mark it fixed once it's in 3.2.1
Fixed, committed to the 3.2.1. stream in >20060815.
Created attachment 47912 [details] -REVERSE- Patch proposal for 3.2.1 for this defect
+1 for 3.2.1.
Verified in M20060830-0800.
Committed in >20060908. Add an attribution for the patch.
*** Bug 136847 has been marked as a duplicate of this bug. ***
