Community
Participate
Working Groups
I'm trying to contribute items in a MultiPageEditor on a per nested-Editor basis. The method I'm following is to create a separate SubActionBar for each nested-editor and activate/deactivate as setActivePage/setActiveEditor is being called on my MultiPageEditorActionContributor. I believe everything is being called, but activate/deactivate seem to cause no effect on the actual ToolBar actions, even after calling updateActionBars().
Created attachment 15952 [details] A testcase plugin demonstrating my SubActionBars problem. Most of the demo code is in MultiPageEditorContributor. I've added two new SubActionBars and two new Actions that I'm trying to hide depending on the active nested-editor.
Punting to RC1.
NE to investigate for RC3
There is major breakage here: - The editor's ToolbarManager gets dirtied when one of the SubToolBarManager's visibility changes, but this does not get propagated to the containing CoolBarManager. Should use a subclass of ToolbarManager whose markDirty() method propagates to the CoolBarManager. E.g. have getToolBarManager() call: /** * Creates the tool bar manager for the editor. * This propagates any dirtying up to the parent cool bar manager. */ private ToolBarManager createToolBarManager(final ICoolBarManager coolBarManager) { return new ToolBarManager(coolBarManager.getStyle()) { public void markDirty() { super.markDirty(); coolBarManager.markDirty(); } }; } - If this is fixed, then the corresponding ToolBarContributionItem gets told to update(), but this is a no-op. It should call update(true) which does an update() on the ToolBarManager. e.g. add: /* (non-Javadoc) * @see org.eclipse.jface.action.IContributionItem#update() */ public void update() { update(null); } - If this is fixed, then the initial state is still wrong. The items on the SubToolBarManagers have visible==true, even though they had visible==false when first added. Their visibility state gets whacked in EditorActionBars.setVisible. EditorActionBars should not reach into the state of the SubToolBarManager or its items. Should use the IContributionManagerOverrides mechanism to override the enablement state instead (as is done for menus). Still need to force an update when the visibility is changed. - Also: could optimize SubContributionManager.setVisible to only do work if the state changes. That is, add: if (this.visible == visible) { return; } Can only do this once the whacking above is fixed. The invariant to be maintained is: the SubContributionManager's visibility is the same as for all the SubContributionItem wrappers for its items. Changes in this area are notoriously fragile. Deferring to 3.2 as it's too risky for 3.1.
s/update(true)/update(null)
The workaround is to add all actions and make them always visible, but update their enablement state accordingly when the active nested editor changes.
Doug, this is a pretty serious issue. Can you look at it for 3.2?
Moving Dougs bugs
Deferring
This bug is marked P2/major with a target milestone of 3.3. Did anything get done?
No, this slipped through the cracks. I'm not entirely sure why it landed in my bucket at all - my experience with these components has been restricted to scary stories told 'round the campfire by a flashlite-lit Paul. Paul, I've confirmed this is still an issue but am hesitant to play Jenga in this area. How would you like to handle this?
Assume you meant to give this to Paul?
Is this related to bug 71923?
(In reply to comment #13) > Is this related to bug 71923? No, this is coolbar related, and it looks like bug 71923 is a workbench window with a toolbar. PW
Updated as per http://wiki.eclipse.org/Platform_UI/Bug_Triage PW
I seem to have the same issue. I'm extending IMP's UniversalEditor, using a PartListener to call activate and deactivate of a SubActionBar. Same behavior as reported. I've tried to 'manually' set the visibility of the embedded contribution items, that helps a bit, but not satisfactory since sometimes they don't reappear (when the focus moves to a different part of the perspective).
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
