Community
Participate
Working Groups
Build Identifier: Version: 4.2.0 Build id: I20120315-1300 In the e4xmi it should be possible to add a "Visible-When condition" to HandledMenuItems which evaluates the outcome of the @CanExecute-annotated method in the Handler-Class. This should work in an similar manner as in Eclipse 3.x with the <visibleWhen checkEnabled="true"></visibleWhen> part of the command-menu-contribution. Reproducible: Always Steps to Reproduce: 1.open the Application.e4xmi 2.select some popup menu -> HandledMenuItem 3.select a @CanExecute = true in the Combo "Visible-When Expression"
I would prefer an additional @CanBeDisplayed (or @IsVisible) annotation which can optionally by applied to a handler method. I think this would be more flexible and straight forward to use. - Next to the normal use cases, I can also think of the want to hide a menu item, but still have the command accessible through the key binding (i.e. user customization). - It makes the handling similar to "@CanExecute". Higher level functions could use EHandlerService.canBeDisplayed() for processing. The possibility to use core expressions should be an additional or alternative option.
In general the handler is not responsible for UI element visibility, that has to be specified at the UI level when the menu or tool item is placed. PW
I would vote for a general solution to dynamic java visible-when calculations which are not only needed on HandleItems (Toolitem/MenuItem) but also on: * Menu * Toolbar The application model already has a notion of it (one has derive from MExpression). The renderer though can currently only work with MCoreExpression (they even blindly cast to it!). In think in 4.3 we could make this more flexible by adding an abstraction
I think we have visible-when expressions since a while. Rolf, can this one be closed?
Yes we have visible-when expressions. However, I am not aware of any expression that can be used to hide the menu item when the handler cannot execute. Furthermore, I don't think there is any tag on the item that could be added to accomplish similar behavior.
We do have code expressions which could define similar conditions as the can method so IMHO we have one way of solving the requirements here. Marking as works for me.
Can you please provide me with an example how I could do this. I would be happily apply that in the products we are developing. Note that there is no one-to-one relation between menu items and handlers, that is what the command infra structure is for. So what should my programmatic visible-when expression look like to call the @CanExecute of the current active handler?
(In reply to Rolf Theunissen from comment #7) > Can you please provide me with an example how I could do this. I would be > happily apply that in the products we are developing. > Note that there is no one-to-one relation between menu items and handlers, > that is what the command infra structure is for. So what should my > programmatic visible-when expression look like to call the @CanExecute of > the current active handler? I think Bug 484398 implemented that, but tbh. I never used it in real projects. IIRC I tested it and it worked.
Bug 484398 provides another way to provide a visibility expression. To accomplish hiding of menu items that do not have an handler that is active: 1. For direct menu items, you could add @CanExecute and @Evaluate on the same method. Then add the class-uri both to the DirectItem and to the Imperative active-when expression. 2. For handled menu items, an class should be created with an @Evaluate. In this method you should inject the handled menu item, get the command for the item, ask the handler service if the command is active (i.e. all that is needed to do the evaluation to decide if the menu item is active) This all is clumsy, inconsistent and slow (due to multiple execution of the same code). I think that introducing a TAG for this would make more sense. The tag is similar to a check-mark on the menu item that states if it should be shown if it is inactive.
