Eclipse Search

Loading

Jan 5, 2009

Commands Part 2: Selection and Enablement of IHandlers

In the last tip, we saw that a Handler can be declared separately from a Command. This enables for multiple handler declarations for the same command. We can also customize when a handler is active and visible, thru plugin.xml itself. A handler that doesn't have any of these conditions is called as "default handler". When no other handler is associated with a command in a particular context, then the default handler will be the handler that gets executed. Remember, at any given point of time, there is at most only one handler is associated with a command. Lets have a look into how a particular handler is selected for a given context.
A handler can be specified with activeWhen condition using the expression language. Say for our command, we have two different handlers. One should be active when the current selection is an IFile and the other should be active when the current selection is IFolder. The expression for these would look like:

<handler
      class="com.eclipse_tips.commads.SomeCommandHandler1"
      commandId="com.eclipse-tips.commands.someCommand">
   <activeWhen>
      <with
            variable="selection">
         <iterate
               operator="or">
            <instanceof
                  value="org.eclipse.core.resources.IFile">
            </instanceof>
         </iterate>
      </with>
   </activeWhen>
</handler>
<handler
      class="com.eclipse_tips.commads.SomeCommandHandler2"
      commandId="com.eclipse-tips.commands.someCommand">
   <activeWhen>
      <with
            variable="selection">
         <iterate
               operator="or">
            <instanceof
                  value="org.eclipse.core.resources.IFolder">
            </instanceof>
         </iterate>
      </with>
   </activeWhen>
</handler> 


I'll save the explanation for the expression language for a separate tip, but for now a short one line desc: the first handler will be enabled when the selection current contains at least one IFile and the second handler will be enabled when the selection contains at least one IFolder. This raises to two questions.
1) What if the selection is just an IProject?
In this case, as none of the handlers are eligible, the command is disabled. This is where the default handler, if you have provided one, would be associated with the command (and the command will be enabled).
2) What if the selection contains both IFile and IFolder?
Now both the handlers are equally qualified to handle the command. But since the framework cannot pick one randomly the command is simply disabled. Even if you have provided a default handler, it won't be associated with the command, because the other two handlers are more specific than the default one.
How is the "specificness" of a handler is defined? It depends on the conditions that you give in the activeWhen expression. The order is defined in the ISources class. You can go thru the complete set there, to get a glimpse of the most commonly used ones, the order from least specific to most specific is like this:
  • Active Context (activeContexts)
  • Active Actions Sets (activeActionSets)
  • Active Shell (activeShell)
  • Active Workbench Window (activeWorkbenchWindow)
  • Active Editor Id (activeEditorId)
  • Active Part Id (activePartId)
  • Current Selection (selection)
If a handler has activeWhen defined with active context and the other one with current selection, the second one will be selected as the selection is more specific than the active context. The activeWhen for all the handlers are evaluated and the one that returns true for the most specific condition is selected. When two handlers return true for the available most specific condition (like the selection having both IFile & IFolder in our case), no handler will be associated with the command.
All these things are done without even loading your handler in the memory. Even without loading your plugin! 
In the previous tip, we saw how a handler is selected with the activeWhen expression, when more than one handler is declared. Now assuming a handler is selected, whether to enable the command or not, is determined by the enabledWhen expression.
In our previous example, we saw the handler that is active when the selection at least contained one IFile. Now lets we want to enable it only when the total count of the selection is 2. We can specify it as:

<handler
      class="com.eclipse_tips.commads.SomeCommandHandler1"
      commandId="com.eclipse-tips.commands.someCommand">
   <activeWhen>
      <with
            variable="selection">
         <iterate
               operator="or">
            <instanceof
                  value="org.eclipse.core.resources.IFile">
            </instanceof>
         </iterate>
      </with>
   </activeWhen>
   <enabledWhen>
      <with
            variable="selection">
         <count
               value="2">
         </count>
      </with>
   </enabledWhen>
</handler>

 
So the handler will be active and associated with the command, if the selection contains at least one IFile. Still the command will be enabled only if selection has exactly 2 elements. activeWhen and enabledWhen are similar - with respective to the expression language and lazy loading of the plugin until the command is executed. But there is small difference - your handler might be loaded iff the enabledWhen expression returns true and your plugin is already loaded. The enablement algo works this way:
  • No enabledWhen specified, plugin is not loaded - command is enabled
  • No enabledWhen specified, but plugin is loaded - consult handler.isEnabled() and set command accordingly
  • enabledWhen specified, returns false, command is disabled (no matter plugin is loaded or not)
  • enabledWhen specified, returns true, plugin is not loaded - command is enabled
  • enabledWhen specified, returns true, plugin is loaded - consult handler.isEnabled() and set command accordingly
So far we saw commands, handlers and their enablements. But what about generalizing a command? That can be done by adding parameters for a command. And that would be the next tip in this series.

Update (31-Mar-2009): Thanks to Hiroki Kondo, a Japanese version of this blog entry is available here.


See also:
Part 1: Actions Vs Commands
Part 3: Parameters for Commands
Part 4: Misc items ...
Part 5: ISourceProvider & dynamically updating Commands
Part 6: 'toggle' & 'radio' style menu contribution

13 comments:

  1. Your article is very interesting and useful. Thanks for that.

    It would be interesting to explain how can I programmatically change the enabled state.

    ReplyDelete
  2. Thanks for this nice article.

    How would you define multiple possible class instances for a same handler (is selection instanceof class1 OR instanceof class2)?

    ReplyDelete
  3. Is it possible to show/hide a menuitem in menu based upon object variable state?

    ReplyDelete
  4. @Anubhav,
    Yes. you can make use of the enabledWhen in your handler extension point to use the variable. You can also override the isEnabled() method

    ReplyDelete
  5. Hi Prakash,
    I guess enabledWhen will only enable/disable the menu item, but I want to show/hide (add/remove) menu items.

    ReplyDelete
  6. @Anubhav,
    Sorry, I should have read it properly. When you add a command to a menu in the extension point, use the visibleWhen element

    ReplyDelete
  7. Using the OR elements requires to use iterators (at least it's the way i do it ^^).

    Using an example from above it would produce something like this:

    <activeWhen>
    <with variable="selection">
    <or>
    <iterate operator="or">
    <instanceof value="your.first.class">
    </instanceof>
    </iterate>
    <iterate operator="or">
    <instanceof value="your.second.class">
    </instanceof>
    </iterate>
    </or>
    </with>
    </activeWhen>

    I hope this works for you.

    ReplyDelete
  8. Strangely enough the
    with variable="selection"
    does not work for me.

    However using
    with variable="activeMenuSelection"
    does the trick.

    Could you please explain the difference?

    ReplyDelete
  9. Thanks for this clear and very helpful article. The whole area of commands and core expressions is so badly documented by Eclipse, this makes life a lot easier.

    ReplyDelete
  10. Hi Prakesh,
    I read above where you said I can override isEnabled(). What triggers the handler's isEnabled() method to be called? I have overridden isEnabled() to check the state of two objects. However, the menu item for this handler does not update it's enabled state (gray/not gray) until after different menus are opened/closed. I read your commands part 5, but I can't use ICommandService, since we use v3.3.

    ReplyDelete
  11. I want to enable a toolbar button in eRCP clipse which i created via extensions. Can some one help by mentioning how to programmatic enable/disable the toolbar items.

    Parvez Ahmad Hakim
    Srinagar Kashmir

    ReplyDelete
  12. Hi Prakash

    I programmatically activate the context, now I want the commands that get active with it..

    is there a way to capture this information ?

    ReplyDelete