Community
Participate
Working Groups
Build: Eclipse 4.3.2 M20140108-1810 Bug 186800 added support for IWorkbenchWindowControlContributions to be able to request a resize/update by calling: getParent().update(true); The parent would be the ToolBarManager for that containing toolbar. The contribution's parent is no longer filled in with 4.x. A workaround is to traverse up the widget hierarchy to find the containing ToolBar, whose data element will be the ToolBarManager.
(In reply to Brian de Alwis from comment #0) > A workaround is to traverse up the widget hierarchy to find the containing > ToolBar, whose data element will be the ToolBarManager. Oops didn't mean to add that without more testing. Unfortunately it's not quite sufficient as we have a couple of levels of wrapping that gets in the way, such that the isDynamic() check is never propagated: MToolBar has an ToolBarManagerRenderer ToolBarManagerRenderer creates a ToolControlContribution ToolControlContribution creates a CompatibilityWorkbenchWindowControlContribution CompatibilityWorkbenchWindowControlContribution creates the actual specified class. I'm thinking that we should make CompatibilityWorkbenchWindowControlContribution implement IContributionItem and delegate to the actual IWWCC, and have ToolControlContribution delegate to the contribution object that it created if it implements IContributionItem.
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. -- The automated Eclipse Genie.
Can someone explain if and where the problem persist? I would then like to provide a patch for it. What repository IWorkbenchWindowControlContributions is located in? I only can find WorkbenchWindowControlContribution wich already extends ControlContribution and thus should get its parent set as soon as it is added to a manager. For me it simply seems that WorkbenchWindowControlContribution is never directly added to a manager but creates the control directly using delegateCreateControl.
(In reply to Christoph Laeubrich from comment #3) > Can someone explain if and where the problem persist? I would then like to > provide a patch for it. > What repository IWorkbenchWindowControlContributions is located in? I only > can find WorkbenchWindowControlContribution wich already extends > ControlContribution and thus should get its parent set as soon as it is > added to a manager. > > For me it simply seems that WorkbenchWindowControlContribution is never > directly added to a manager but creates the control directly using > delegateCreateControl. The attached RPC in Bug 186800 clearly shows the bug, it has NPEs because the parent is not set. I couldn't find IWorkbenchWindowControlContributions, so I don't think it exists. In an E4 the contributed tool controls are managed via ToolControlContribution and CompatibilityWorkbenchWindowControlContribution. If I am correct, ToolControlContribution provides the translation of the extension point to a model entry. CompatibilityWorkbenchWindowControlContribution should be a proxy between the E4 model and the legacy WorkbenchWindowControlContribution.
The parent is still not set or proxied to the E4 counterparts.
