Bugzilla – Full Text Bug Listing
| Summary: | Shift+Enter gives strange character 0x03 in Text widget | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Markus Keller <markus.kell.r> | ||||
| Component: | SWT | Assignee: | Platform-SWT-Inbox <platform-swt-inbox> | ||||
| Status: | CLOSED WONTFIX | QA Contact: | Silenio Quarti <Silenio_Quarti> | ||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | daniel_megert, eclipse.felipe, skovatch | ||||
| Version: | 3.6 | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Mac OS X | ||||||
| Whiteboard: | stalebug | ||||||
| Attachments: |
|
||||||
Shift + return is taking a different path through the key handling code. It ends up in Control.insertText because it doesn't map to some other NSResponder message, and we aren't calling translateTraversal in insertText. Patch coming in a moment... Created attachment 178877 [details]
Fix
Call translateTraversal in insertText as the enter key may find its way into this method.
insertText does not need to return boolean as it's a notification, but that's a bigger and unrelated patch. Fixed > 20100920. Can't not call translateTraverse in insertText. This has caused Bug 343093 btw, the bugzilla is wrong for this fix, see https://bugs.eclipse.org/bugs/show_bug.cgi?id=325230#c18 What mac are you on Markus ? 10.6 or 10.5 ? I removed the fix but I do not see the shift+enter bug. I'm on 10.6. I can check it again tonight (my Mac is at home, and I don't trust VNC to understand the difference between the Return and the Enter key). Markus, I removed the fix from Scott. I can't reproduce the problem. Let me know if the bug comes back and we will look at another approach for solve it (we really can't use the fix Scott released as it breaks Japanese input). Thank you Sorry, the Snippet didn't actually show the real problem, which is the missing Traverse event in Shift+Enter. Add this to the snippet to see the events:
text.addTraverseListener(new TraverseListener() {
public void keyTraversed(TraverseEvent e) {
System.out.println(e);
}
});
The fix was indeed not good, since it also caused double Traverse events in some cases. HEAD doesn't have that problem any more, but the original problem is back now (the missing Traverse event on Shift+Enter).
I don't know what to tell you. I don't see the problem, I am running your snippet+traverse_listener with SWT from HEAD.
This is the output for shift+enter:
Event {type=31 Text {} time=35617374 data=null x=0 y=0 width=0 height=0 detail=4}
Is your keyboard german or something else ?
I have Swiss German keyboard, but I still have the bug when I switch to U.S. Please try it again with the typed TraverseListener from comment 9. That one also gives you the stateMask and the keyLocation, so that you can be sure you see the right event (not e.g. one without Shift). With that and the patch from bug 293932 (to make the Events more readable), I get this on Enter: TraverseEvent{Text {} time=110304824 data=null character=' '=0xd keyCode=0x1000050 keyLocation=0x2 stateMask=0x0 doit=false detail=4} On Shift+Enter, I don't get a Traverse event. Same behavior when I show the Mac OS Keyboard Viewer, hold down Shift on the keyboard and then click Enter on the numpad of the on-screen keyboard. You can also use the ControlExample to see the events. - for Shift+Enter, I get: KeyDown [1]: KeyEvent{Text {} time=111487897 data=null character='\0'=0x0 keyCode=0x20000 keyLocation=0x4000 stateMask=0x0 doit=true} KeyDown [1]: KeyEvent{Text {} time=111488673 data=null character=''=0x3 keyCode=0x1000050 keyLocation=0x2 stateMask=0x20000 doit=true} - for Enter, I get: Traverse [31]: TraverseEvent{Text {} time=111495001 data=null character=' '=0xd keyCode=0x1000050 keyLocation=0x2 stateMask=0x0 doit=false detail=4} KeyDown [1]: KeyEvent{Text {} time=111495001 data=null character=' '=0xd keyCode=0x1000050 keyLocation=0x2 stateMask=0x0 doit=true} KeyDown [1]: KeyEvent{Text {} time=111495001 data=null character=' '=0xa keyCode=0x1000050 keyLocation=0x2 stateMask=0x0 doit=true} I did some more testing on another Mac with different keyboards. I could not reproduce the Shift+Enter problem with recent Apple keyboards (US or Swiss German models). But I could reproduce with a Lenovo Swiss German Windows keyboard (same behavior as my old Swiss German keyboards from Macally and Apple at home). I can also reproduce when I connect to the Mac via UltraVNC from a Lenovo Windows 7 notebook (engage NumLock to turn the Return key into an Enter key). So it looks like a problem that only shows up with certain keyboards (independent of the keyboard settings in the OS). I also tried to see what System Preferences > Keyboard > Shortcuts does with the keys. The new Apple keyboards don't allow me to use Enter or Shift+Enter as shortcuts, but the older keyboards allow them. In the snippet, I can produce the 0x03 character and the missing traverse event also with the new Apple keyboards, but I have to press Ctrl+Option+Enter instead of Shift+Enter. Tentatively setting milestone to 3.7 RC1, but this could also be skipped if no safe fix can be found. We are not going to get this fixed in 3.7. This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. If the bug is still relevant, please remove the "stalebug" whiteboard tag. |
3.6 Shift+Enter (Enter from the numpad, not Return) gives a strange invisible character 0x03. In the Find/Replace dialog, we now use Shift+Return to find backwards, but this doesn't work on Cocoa, since we get this character instead of the expected Traverse event. Shift+Return is OK. BTW: Ctrl+Return and Ctrl+Enter also result in strange characters, but that's maybe just platform behavior (I do get the expected Traverse event). public class Snippet { public static void main(String[] args) { Display display = new Display(); Shell shell = new Shell(display); shell.setLayout(new GridLayout(1, false)); final Text text = new Text(shell, SWT.MULTI | SWT.BORDER); GridData layoutData = new GridData(SWT.FILL, SWT.FILL, true, false); layoutData.widthHint= 300; layoutData.heightHint= 60; text.setLayoutData(layoutData); final Label label= new Label(shell, SWT.NONE); layoutData = new GridData(SWT.FILL, SWT.FILL, true, false); layoutData.widthHint= 300; layoutData.heightHint= 60; label.setLayoutData(layoutData); text.addModifyListener(new ModifyListener() { public void modifyText(ModifyEvent e) { String origText = text.getText(); byte[] bytes; try { bytes = origText.getBytes("UTF-16BE"); String string = Arrays.toString(bytes); label.setText(string + ": \"" + origText + "\""); } catch (UnsupportedEncodingException e1) { e1.printStackTrace(); } } }); shell.pack(); shell.open(); while (!shell.isDisposed()) { if (!display.readAndDispatch()) display.sleep(); } display.dispose(); } }