Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 369882

Summary:

[Contributions] visibleWhen and checkenabled=true not working correctly in menu

Product:

[Eclipse Project] Platform

Reporter:

Markus Krüger <webmaster>

Component:

Assignee:

Platform UI Triaged <platform-ui-triaged>

Status:

CLOSED WONTFIX

QA Contact:

Severity:

normal

Priority:

CC:

pwebster, remy.suen, robin, webmaster

Version:

3.7.1

Target Milestone:

---

Hardware:

All

OS:

All

Whiteboard:

stalebug

Attachments:

Description	Flags
RCP project showing the bug.	none
New application action bar advisor for attached project	none

Description Markus Krüger

2012-01-26 19:23:52 EST

Build Identifier: 3.7.1

Hi,
there seems to be a bug in displaying menu and menu item when using the visibleWhen with checkenabled=true.
I created a simple RCP example where a menu contains one command with visibleWhen and checkenabled=true. The handler of the command is only enabled if one ore more items in the view is selected. If you start the application, then there will be no menu as expected, but the menu doesn't even occur if an item is selected in the view. The expected behavior should be, that the menu appears with one single active command in it. So there is something going wrong here. The same wrong behavior applies to submenus.
One workaround is to duplicate the condition into the visibleWhen of the command and set check enabled to false, but this would mean, that the condition needs to be defined twice. I know a reference to a predefined condition put the logic in one single place, but actually this should not be the way to go, right?
Another bad workaround is, that the bug seems to be fixed, if at least one other command in the menu exists, which has no condition so that it will always be visible. You can even fake it by using a dynamic contribution with only its constructors. This way there would be no visual representation of the dynamic contribution, but the menu is always visible and if the user clicks on it, then nothing pops up because there are no commands visible.

I'll attach my project to this bug.

I hope that I am doing something wrong as we are stuck to eclipse 3.4 due to lotus notes implementation.
The Bug was verified in eclipse 3.4 and 3.7.1 in windows and macosx.

Reproducible: Always

Steps to Reproduce:
See details.

Comment 1 Markus Krüger

2012-01-26 19:26:01 EST

Created attachment 210162 [details]
RCP project showing the bug.

Comment 2 Paul Webster

2012-01-27 09:42:13 EST

The visibleWhen/@checkEnabled=true currently depends on the SWT.Show (menuAboutToShow) event, or the notion that it can be updated dynamically.  But when it is the only item there and it disabled, the menu is empty and there will be no show event.  That's why having one command in the menu that's always visible allows it to work.  The dynamic contribution forces updating of the MenuManager at frequent intervals, and that's why having the empty dynamic contribution in the menu also works.

Perhaps the enabled state can force a menu manager update.

PW

Comment 3 Markus Krüger

2012-01-27 11:02:39 EST

Are we doing something wrong than, or is this a bug in eclipse as the attached plugin rcp shows?

Comment 4 Paul Webster

2012-01-27 11:23:27 EST

(In reply to comment #3)
> Are we doing something wrong than, or is this a bug in eclipse as the attached
> plugin rcp shows?

It's a bug.

PW

Comment 5 Markus Krüger

2012-01-27 17:54:14 EST

Created attachment 210227 [details]
New application action bar advisor for attached project

I found a third workaround which seems to solve the problem in the test project.
The new application action bar advisor registers a listener that listens on source provider changes and then updates the menu recursively.

I need to test it in our real life application and additionally in our lotus notes integration. Maybe doing the update all the time has some side effects, but I do not know this yet.

If this looks not like a good idea, please let me know.

Comment 6 Paul Webster

2012-01-31 08:54:08 EST

(In reply to comment #5)
> I need to test it in our real life application and additionally in our lotus
> notes integration. Maybe doing the update all the time has some side effects,
> but I do not know this yet.
> 
> If this looks not like a good idea, please let me know.

In general this is probably not the way to go.  If you recursively update the menu, it will activate all of the plugins that contribute to the main menu (which is most ui plugins) which will also activate all their core supporting plugins.  Other parts of the framework will then load any other contributions as needed since all of their plugins are active.  Depending on the number of bundles involved, it's a big performance as well as memory consumption hit.

In a small RCP app if it gives the desired results, you would be able to decide if it was necessary or not.  I would strongly advise not doing it in any lotus notes integration :-)  If you feel you need a workaround (this bug won't be addressed in 3.7.x), I would start with the empty dynamic contribution first.

PW

Comment 7 Markus Krüger

2012-01-31 10:49:43 EST

Thank you for the input, especially regarding lotus notes.

Comment 8 Eclipse Genie

2020-05-12 15:33:47 EDT

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. As such, we're closing this bug.

If you have further information on the current state of the bug, please add it and reopen this bug. 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.