| Summary: | [Commands] Menu with command items with visbleWhen attribute checkEnabled=true not updated properly | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Tonny Madsen <tonny.madsen> | ||||
| Component: | UI | Assignee: | Paul Webster <pwebster> | ||||
| Status: | RESOLVED DUPLICATE | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | david.perez.ingeniero, emoffatt | ||||
| Version: | 3.4.1 | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| Whiteboard: | |||||||
| Bug Depends on: | |||||||
| Bug Blocks: | 258152 | ||||||
| Attachments: |
|
||||||
|
Description
Tonny Madsen
Created attachment 116436 [details]
Sample plug-in
The attached plug-in contains
- two identical views with a list with the strings A, B, andd C
- a command Test
- a handle TestHandler with an enabledWhen expression that is true when the current selection is the A element in one of the views
- a menu bar with three items:
- Test (always) - no visibleWhen - should just be enabled/disabled as the handler enablement changes
- Test (checkEnabled) - visibleWhen with checkEnabled=true - should be present exactly when A is selected
- Test (view 1 only) - visibleWhen with expression activePartId = view1-id - should be present when view is active
Whereas the first and the last items are behaving as expected, that is not the case with the second item. Switching between the two views will - sometimes - make the second item reappear as expected - and sometimes not...
(In reply to comment #0) > > But... for command items with a visibleWhen expression with checkEnabled=true > this is not the case (as there are no expression, it will ever change value) > and the parent menus will not get updated until some other command item force > it. This is not necessary, as it is done by the CommandContributionItem listening for the command enabled state change. The command does a manager.update(true); I'd be surprised if the example you provided worked, you've put MenuItems directly in the main menu bar ... that won't change without a Shell layout, no? If I move your menuContribution into the window menu, it works as expected. PW Hmm, not understood. The last item is updated properly even when in the main menu... I just tried to move the items to a sub-menu, and yes it does work. But not in my application :-( I'll be back... Any more information on this, why it does not work in your application? PW I think I'm experiencing this bug:
I have this:
<menuContribution
locationURI="menu:file?after=additions">
<command
commandId="org.eclipse.ui.file.save"
mnemonic="G"
style="push">
<visibleWhen
checkEnabled="true">
</visibleWhen>
</command>
</menuContribution>
I have view A which defines no handler for this commandId.
View B defines a handler in this way:
getViewSite().getActionBars().setGlobalActionHandler("org.eclipse.ui.file.save", new SaveAction());
The action is always enabled.
I expect that when view A is active, no menu item is shown (as there is no active handler), whereas view B is active, a menu item is shown.
What it happens, is that when view B is initially shown, the menu item is shown. This is expected behavour.
Then if I switch to view A, the menu is hidden. This is also expected behavour.
But if I go back to view B, the menu continues to be hidden. I expect it to be shown!.
Does it belong to this bug?
Any workaround to hide menu items with no handlers in order to reduce clutter?
(In reply to comment #5) > I think I'm experiencing this bug: > What it happens, is that when view B is initially shown, the menu item is > shown. This is expected behavour. > Then if I switch to view A, the menu is hidden. This is also expected > behavour. > But if I go back to view B, the menu continues to be hidden. I expect it to be > shown!. This I believe was a bug that was fixed in 3.5, probably Bug 249442 PW Thanks Paul, your guess is right. This is the same problem I experienced! Thanks. Poul, You can set this to fixed now. Whew! :-) *** This bug has been marked as a duplicate of bug 249442 *** |