Community
Participate
Working Groups
I20070110-1600 Currently, there's no way how a drop-down action used in an ActionContributionItem can avoid leaking a Menu widget. The IMenuCreator from IAction#getMenuCreator() is only asked for #getMenu(Control) during the whole lifetime of the ActionContributionItem. IMenuCreator#dispose() is only called when the ActionContributionItem's widget is disposed, which can be as late as shutting down the workbench. The Javadoc of IMenuCreator suggests to keep a reference to the Menu widget and to dispose it each time a new menu is created, but this still leaks one Menu (including all MenuItems and their associated actions) after the menu has been closed. An ugly workaround to handle this problem has been implemented for bug 25904. They now reuse the Menu instance and update it manually whenever a change occurs. This is inefficient and overly complex. A dynamic menu would be more appropriate. I guess the best fix would be a new interface IDynamicMenuCreator that offers getMenu(..) methods like IMenuCreator but where callers will dispose the menu as soon as it is not visible any more. If IDynamicMenuCreator extends IMenuCreator, then the implementation could simply use the code from https://bugs.eclipse.org/bugs/show_bug.cgi?id=64855#c2 after having called Menu#setVisible(..) in ActionContributionItem.
Another solution would be adding a menuHidden listener and disposing the menu there. We successfully use this in org.eclipse.jdt.internal.ui.viewsupport.HistoryDropDownAction: final Display display= parent.getDisplay(); fMenu.addMenuListener(new MenuAdapter() { public void menuHidden(final MenuEvent e) { display.asyncExec(new Runnable() { public void run() { manager.removeAll(); if (fMenu != null) { fMenu.dispose(); fMenu= null; } } }); } });
> What |Removed |Added > ---------------------------------------------------------------------------- > Target Milestone|3.4 M6 |--- Could this be scheduled for 3.5 then? It really is a problem.
The problem is there is not simple solution that doesn't involve a new API path and it is in the action framework ... we don't want to be adding new API to actions. With menus/commands the dropdown toolitems use a menu contribution to fill in the dropdown. It's created on every SWT.Show from the IMenuService and can be filled with commands and/or with a dynamic element. The dynamic element is backed by a CompoundContributionItem (although we opened that up to any ContributionItem in 3.4) and can also return arbitrary ContributionItems. Dynamic elements can be placed in dropdown toolitems, which would then provide the dynamic menu without having the re-entrant problem that IAction+IMenuCreator has. PW
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.
