Community
Participate
Working Groups
Eclipse 3.0 diables a keybinding when the same keySequence with the same contextId is registered more than once. We could do better in such cases: There should be a defined sequence for trying all of the conflicting handler submissions (e.g. depth-first traversal in the plugin-dependencies tree). When a handler submission has set the "handled" attribute to false, the next handler should be tried, etc., until a handler has handled the shortcut. [This is part (a) of bug 33161 comment 8.]
Can you give a concrete example?
I tried to hack a plugin which contributes a "Select All" handler for all Tree and Table widgets to the keybinding Ctrl+A. I used ... <command name="Select All" description="Select all items in a Tree or a Table" categoryId="org.eclipse.ui.category.widget" id="tree.key.selectall"> </command> <handlerSubmission commandId="tree.key.selectall" handler="tree.key.SelectAllHandler" /> <keyBinding commandId="tree.key.selectall" contextId="org.eclipse.ui.contexts.dialogAndWindow" keyConfigurationId="org.eclipse.ui.defaultAcceleratorConfiguration" keySequence="Ctrl+A"> </keyBinding> ... to contribute my subclass of AbstractHandler. In getAttributeValuesByName(), I set the attribute "handled" to false iff the current focus control is not a Table or a Tree. I expected the keyboard/command service to fall through the first handler and try the second one iff there are multiple handlers for the same contextId.
The handled attribute is a hack to support the migration of RetargetAction to the commands architecture. It is meant to avoid swallowing the key, but not to provide a fallthrough mechanism. I'm sorry that this isn't better documented. Why don't you want to use the default select all handler?
No response. Closing as WORKSFORME. Please re-open if this is still a problem.
