Community
Participate
Working Groups
GM3 Clients of action bars may create a number of SubToolBarManagers on their IToolBarManager (ex. multipage editor). The client will typically set one SubToolBarManager visible, the rest invisible and call updateActionBars. However, CoolBarManager.update(boolean) does not call update on its CoolBarContributionItems. Thus if the visibility of one of the items in a CoolBarContributionItem has changed, this change will not be visible. The attached hack of MultiPageContributor demonstrates the problem using our multipage editor example. A proposed fix is to update the CoolBarContributionItems at the end of CoolBarManager.update(boolean) // update CoolBarContributionItems items = getItems(); for (int i = 0; i < items.length; i++) { CoolBarContributionItem cbItem = (CoolBarContributionItem) items[i]; cbItem.update(force); } A Workaround is for the client to explictly update the toolbar. ex. actionBars.updateActionBars(); actionBars.getToolBarManager().update(false);
Created attachment 1595 [details] source for hacked MultiPageContributor
Peter could you verify the workaround works for you.
Workaround seems to work. Thanks!
Calling update for each coolbar item in update for the CoolBarManager is probably not a good idea (unnecessary, may cause flash). It seems like the fix would be to have updateActionBars() call CoolBarManager.update().
Changed SubActionBars.updateActionBars() to handle the case where the action bar has its own toolbarmanager (i.e., it's a cool item).
The fix for this somehow got lost when SubActionBars was moved from org.eclipse.ui.internal to org.eclipse.ui.
Should put the fix back in for 2.1.1. public void updateActionBars() { IToolBarManager mgr = getToolBarManager(); if (mgr instanceof CoolItemToolBarManager) { mgr.update(false); } parent.updateActionBars(); fireActionHandlersChanged(); }
Approved.
Released fix into 2.1.1 and head streams.