Commands

Commands are managed by the org.eclipse.ui.commands extension point and the ICommandService.

An example of using the extension point to create a command:

<extensionpoint="org.eclipse.ui.commands"><categorydescription="Actions take at lunch time."id="z.ex.view.keybindings.category"name="Lunch"></category><commandcategoryId="z.ex.view.keybindings.category"description="Go for the taco."id="z.ex.view.keybindings.eatTaco"name="Eat That Taco"></command></extension>

Using an IActionDelegate to execute a command

In 3.1 and 3.2 there is no declarative support for a menu item to execute a command. But you can write an IActionDelegate (like GenericCommandActionDelegate) that can be used in the standard extension points (org.eclipse.ui.actionSets, org.eclipse.ui.popupMenus, org.eclipse.ui.editorActions, and org.eclipse.ui.viewActions) and use it to execute the command.

We need to do these things to wire our command to a menu item:

Define an action in an extension point using plugin.xml markup

Connect this action to our IActionDelegate instance (also in plugin.xml)

Tell our IActionDelegate which command to execute (also in plugin.xml)

your action definition looks more like a keybinding definition. You are specifying the command id and any parameters needed for that action.

We specifed the action using the <class/> element instead of the class attribute ... you'll get a couple of warnings, ignore them.

The definitionId that is currently in the <action/> element is for linking up legacy actions to a keybinding through a command. For example, you've had a ShowMyViewActionDelegate since 3.0, and you want to attach a keybinding to it. We don't want to use that.

We have just shown the plugin.xml markup to trigger a command from within an action. Since the action can be inserted into a menu, this approach allows commands to be triggered by menu items. The glue between actions and commands is a single generic IActionDelegate implementation (shown below). All of the specific behavior code is now unified in the command and its handler. We no longer need an action delegate with a specific run() method for every menu item; consequently we don't need to link ActionSets to commands with the definitionId.

Known Issues:

When you start up eclipse you'll get warnings about your actions not having a class attribute. It's not an error, and won't effect the action performance.

You'll also see the actions in the Uncategorized section of the keybindings page. You can bind keys to them but they won't work from the keybinding. That's OK, you should be binding keys to the command not the action.

Generic Command Action Delegate

We'll need a more robust implementation, but in 3.2 your action delegate needs to look something like the class below. I've only tested this with org.eclipse.ui.actionSets, but it should work with the viewActions, editorActions, and popupMenus extension points as well. The latest version of the code lives in HEAD in the org.eclipse.ui.tests plugin: GenericCommandActionDelegate.java

Handlers

Handlers are managed by the org.eclipse.ui.handlers extension point and the IHandlerService. Many Handlers can register for a command. At any give time, either 0 or 1 handlers will be active for the command. A handler's active state and enabled state can be controlled declaratively. See Command Core Expressions for a more complex description of the declarative expressions. Handlers are responsible for interpreting any optional command parameters using the ExecutionEvent parameter.

If you want the handler to evaluate an enablement expression you can do that using the expression parameter of the
activateHandler() method. Here is how you need to setup your expression in order to properly work tracking
selection changes:

Expression expr =new Expression(){publicfinal EvaluationResult evaluate(final IEvaluationContext context){Object sel = context.getVariable(ISources.ACTIVE_CURRENT_SELECTION_NAME);(return EvaluationResult.TRUE/FALSE depending on how much you like the selection)}publicvoid collectExpressionInfo(final ExpressionInfo info){// You need this to cause the expr to be evaluated on selection events
info.markDefaultVariableAccessed();}};

KeyBindings

KeyBindings are managed by the org.eclipse.ui.bindings extension point and the IBindingService. Keybindings cannot be updated programmatically.

A key binding is active when the context is active. A keybinding is associated with a command (with optional parameters specified by parameter id and value). If a command has a handler while the keybinding is invoked, the handler extracts the command parameters specified by the keybinding from the ExecutionEvent and invokes the appropriate action.

Contexts

Contexts are managed by the org.eclipse.ui.contexts extension point and the IContextService.

Most contexts are created by the extension point, and activated programmatically when appropriate. But you can create contexts programmatically as well. The active contexts usually form a tree, although in the case of keybindings this tree is narrowed down to a branch.

handlers.verbose.commandId allows you to track the information about a specific command that isn't working. org.eclipse.jdt.ui.navigate.open.type is the open type dialog (normally CTRL+SHIFT+T) and org.eclipse.ui.edit.copy (commented out) is COPY (normally CTRL+C)