Bug 332184

Comment 1 Fan Peng 2010-12-08 22:20:19 EST

Created attachment 184834 [details]
Demo

An simple eclipse project to reproduce this issue

Comment 2 Fan Peng 2010-12-08 22:26:13 EST

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".

Comment 3 Hitesh 2010-12-09 05:44:24 EST

Adding Lakshmi for comment.

Comment 4 Lakshmi P Shanmugam 2010-12-09 08:33:28 EST

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.

Comment 5 Paul Webster 2010-12-09 11:05:24 EST

Was this carbon or cocoa?

PW

Comment 6 Scott Kovatch 2010-12-09 13:13:18 EST

(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?

Comment 7 Lakshmi P Shanmugam 2010-12-16 09:09:38 EST

(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

Comment 8 Eclipse Webmaster 2019-09-06 16:14:52 EDT

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.

Comment 9 Eclipse Genie 2021-10-02 11:34:18 EDT

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.