Community
Participate
Working Groups
When Ctrl+Numpad_Enter is not defined in the active key-binding scope, it activates the command bound to Ctrl+M, rather than being sent as a key event. Test scenario: Open a file with Text Editor, Ctrl+Numpad_Enter will maximize/restore the edit window.
When "Ctrl+Numpad_Enter" is pressed, the keyCode is 0x1000050 and the character is 0xD. The first matching key stroke is "Ctrl+Numpad_Enter" (obviously). However, we have fall-through code to accomodate characters like "Ctrl+&" and "Ctrl+Shift+&" (example for U.S. keyboard). This fall-through code translates the 0xD into a "Ctrl+M". It might be possible to filter out numpad keys in some way from this fall-through code.
Probably similar to the Ctrl+Numpad_Enter key grabbing, the Ctrl+Shift+Backspace key (not defined in the textEditor context) does not arrive as a key event to the widget - instead, the command bound to Ctrl+Backspace is run. The key binding service should not take over keys which are not defined in the active scope!
But, as I said, a user would expect that pressing "Ctrl+Shift+7" might match "Ctrl+Shift+7" or "Ctrl+Shift+&", for example. While the "Numpad_Enter" scenario is different from the perspective of the user, SWT does not provide any information to distinguish these cases easily (i.e., there is no facility for retrieving the keyboard layout). I imagine I might build a list of known problem keys, and simply make a special case for them.
*** This bug has been marked as a duplicate of 46588 ***
