Community
Participate
Working Groups
Ctrl+Tab can not be set as a key binding for any command/action using the new incarnation of the KeysPreferencePage. This is partly by design of the page, and partly due to the nature of SWT. This happens because the text widget allows all tab traversal, and SWT treats Ctrl+Tab as a traversal operation in a text widget. This could be fixed either by SWT, or by the KeysPreferencePage itself.
You can paste key bindings with the mouse into the input field, but the Add button doesn't apply Ctrl+Tab as a new key binding. I am not sure whether the existing Ctrl+Tab binding was working at all after upgrading to 3.0M3.
Created attachment 5946 [details] KeySequenceText patch This patch allows you to bind to any valid key sequence that you can paste into the text field. It creates a modification listener that updates the sequence based on changes to the underlying text widget.
applied patch. i don't think this is sufficient to fix this problem. assigning ctrl+tab is desired by many people, and needing to open a text editor, type in the formal grammar for the key sequence (which may be different than the translated key sequence), copy and paste it, is non-intuitive to say the least. keep this bug open; we need to talk to steve n. about the proper way to fix this.
REMOVED PATCH. with this patch, on win xp at least, simply opening the Keys preference page with a clear workspace, using the mouse to place the focus in the key sequence text widget, and pressing/holding 'shift' causes an immediate stack overflow error. there must be re-entry on the modify listener.
I see no such problem on my end. I do see a NullPointerException in KeysPreferencePage code, with repeat entries from KeySequenceText. Are you getting the two mixed up? The NullPointerException is caused by a missing check for null on line 1255 of KeysPreferencePage. I'll attached my stack trace.
Created attachment 5975 [details] Fresh log file containing the stack trace
From a conversation with Veronika Irvine: There is not enough information in a traverse event to determine whether the "Ctrl" mask was down. To make this determination, we need an Event or a KeyEvent. This can be trapped at the global filter level, and the traversal cancelled. As a note, in addition to this, Motif arrow traversal cannot happen on text widgets. Only "Tab" and "Shift+Tab" are required.
Created attachment 6021 [details] Patch for KeySequenceText This fix makes it so that KeySequenceText allows tab traversal only if the tab has no modifiers keys or only the shift modifier key. Otherwise, the traversal is blocked. This allows users to insert 'Ctrl+Tab', 'Ctrl+Shift+Tab', etc., etc. -- operating system permitting.
chris: review/apply. A conversation with Steve helped lead to a decent solution. It is still very slightly hacked because it assumes that 'Tab' and 'Shift+Tab' are the basic tab traversal keys. A reasonable assumption, but it would be better if SWT exported the traversal keys as constants.
*** Bug 42537 has been marked as a duplicate of this bug. ***
*** Bug 39359 has been marked as a duplicate of this bug. ***
Again, please apply BOTH patches. Bug 39359 relies on the first patch.
applied both patches
Fixed > 20030915
