I am developing an Eclipse RCP application and have defined a custom context (org.eclipse.ui.contexts) for my editors. This context is activated whenever I invoke one of my editors.
Further, I have defined a single-key key binding (org.eclipse.ui.bindings) that I have scoped to this context which, when typed within the editor context, invokes a command/handler (I'll use the letter 'J' for this example).
Everything works as expected. When I launch/select one of my custom editors, the context is activated and 'J' executes my handler. When I launch/select a view part, my custom editor's context is deactivated and 'J' no longer executes the handler. However, when I click in a Text widget somewhere in the window trim area--let's say the Quick Access field--and type the letter 'J', the keystroke is consumed and executes my handler, behavior I do NOT want.
The reason is that selecting another workbench part has the effect of activating its context and deactivating the previous one. However clicking anywhere else in the workbench window area (other than another part) does NOT deactivate the previous context. I am sure this is by design and is a perfectly reasonable approach. However, it prevents me from defining single-key key bindings.
Has anyone a) run into this problem before and b) if so, how did you solve it?
For now I am using a complete hack that involves using a global listener to disable the key binding service entirely on detecting entry into a Text widget, and re-enabling it on exit from the Text widget.
