Community
Participate
Working Groups
I use an org.eclipse.jface.action.MenuManager for a sub-menu in the context-sensitive menu. Items are added to that sub-menu according to the current selection, and in some cases, there may be no items added. In the 2.0 series, the sub-menu item would be disabled if it contained no items. On 2.1 RC1 and RC2, it draws the sub-menu item as if it's enabled but, of course, pops up no sub-menu when selected. The new behaviour is very confusing. Note: this is not a repeat of bug 30423, which deals with sub-menus that contain only disabled items; this refers to sub-menus with no items at all.
Created attachment 4123 [details] Empty menu behaviour in 2.0 Under Eclipse 2.0, "New Sibling", which contains no items, is disabled.
Created attachment 4124 [details] Empty menu behaviour in 2.1 Under Eclipse 2.1, "New Sibling" is enabled. Because it has no items in it, no sub-menu pops up.
Simon, please check that this is in fact a regression.
It's not an "unknown" regression... The code to disable the menu item of a sub- menu has been removed for 2.1 because it caused more problems than it solved. For example, when the sub-menu needs to be populated on menuAboutToShow event, if the menu item is disabled, the sub-menu will never be given the chance to populate again. See bug 30833 for a list of bugs related to this problem. See also bug 27019 which is a very much the same as this one.
Is there any work-around you could suggest, other than ensuring that all sub-menus always contain at least one item? For example, is there any way that I could explicitly disable the menu myself? As it stands, all EMF.Edit-generated editors are "broken" in this respect.
I can't think of any workaround at the moment. Unfortunately, with 2.1 release date just days away, I do not have sufficient time to look more into this.
Can someone clarify? Is this a problem that will be fixed in eclipse, or is this an intentional behaviour change that we need to react to?
It is a known problem.
I think Craig's question is if this well be fixed in 2.1.1. We are working on a product that will be based on 2.1.1 and nearing our code shutdown, so we need to know if Craig should workaround this problem or expect a fix.
No plans to fix this for 2.1.1 If that changes, you will see the target milestone field change to reflect this.
Please investigate a fix or workaround for 2.1.1. If the context menu is repopulated entirely each time it is popped up, then the problem mentioned in comment #4 does not matter. It would be a problem if there was a dynamically populated submenu in a non-dynamic context menu. For context menus, I'm comfortable with imposing a limitation whereby if there is a dynamically populated submenu, then the context menu must be dynamic as well. However, this also has to work with main menus.
A potential fix for this problem has been released in the 2.1.1 stream and will be part of the next 2.1.1 build (next week I'm told). I've also updated the HEAD stream with the same changes.
