Community
Participate
Working Groups
Build Identifier: Helios Release 20100617-1415 If we bind the key "CTRL+XXX",when we enter the key "CTRL+SHIFT+XXX",the Java side will handle it as "CTRL+XXX",XXX stands for some keys,especially digit key,symbolic key. Reproducible: Always Steps to Reproduce: 1.Bind CTRL+9 keys to a command. 2.Press CTRL+SHIFT+9 in MAC. 3.The command will be executed.
Created attachment 184834 [details] Demo An simple eclipse project to reproduce this issue
This issue occured in MAC platform.Windows has no problem.I have tracked eclipse source code and found an difference between windows and mac: Method org.eclipse.ui.internal.keys.WorkbenchKeyboard.generatePossibleKeyStrokes has a parameter Event.If CTRL+SHIFT+9 has been pressed,value of Event.character is "(" in windows, In Mac the value is "9".
Adding Lakshmi for comment.
I tested with a SWT snippet and can see this. KeyDown events on pressing Ctrl+1, Ctrl+Shift+1 and Cmd+Shift+1 have the same event.character(=1), but the statemask is correct in all cases. The Shift modifier is not being applied on the key here, not sure if it is expected -- adding Scott to comment.
Was this carbon or cocoa? PW
(In reply to comment #4) > I tested with a SWT snippet and can see this. KeyDown events on pressing > Ctrl+1, Ctrl+Shift+1 and Cmd+Shift+1 have the same event.character(=1), but the > statemask is correct in all cases. The Shift modifier is not being applied on > the key here, not sure if it is expected -- adding Scott to comment. According to Northover & Wilson's SWT reference book the character field should have all of the modifier keys applied to the final value. Ctrl-shift is an odd case, though, because it doesn't normally generate a character. The same is true on Windows. I verified the behavior Lakshmi is seeing in HEAD of Cocoa SWT. What happens on Linux in this case?
(In reply to comment #6) > (In reply to comment #4) > > I tested with a SWT snippet and can see this. KeyDown events on pressing > > Ctrl+1, Ctrl+Shift+1 and Cmd+Shift+1 have the same event.character(=1), but the > > statemask is correct in all cases. The Shift modifier is not being applied on > > the key here, not sure if it is expected -- adding Scott to comment. > > According to Northover & Wilson's SWT reference book the character field should > have all of the modifier keys applied to the final value. Ctrl-shift is an odd > case, though, because it doesn't normally generate a character. The same is > true on Windows. > > I verified the behavior Lakshmi is seeing in HEAD of Cocoa SWT. What happens on > Linux in this case? I just tested the Ctrl+Shift+1 case on Windows and Linux. On both, the shift modifier is applied on the key.character. So, the behavior on mac is inconsistent with windows & gtk
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.
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. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. 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. -- The automated Eclipse Genie.
