Community
Participate
Working Groups
Build Identifier: swt-I20100426-0852-cocoa-macosx-x86_64 Attempting to specify cmd-minus as the key for a "zoom out" menu item. Using item.setAccelerator(SWT.MOD1 | '-') shows the correct command glyphs in the menu item. However, it responds to BOTH cmd-minus and cmd-shift-minus (that's cmd-underline). It should respond only to cmd-minus. If I try different base keys, the shifted and non-shifted versions are correctly distinguished. For example, item.setAccelerator(SWT.MOD1 | 'd'); responds only to cmd-d, and item.setAccelerator(SWT.SHIFT | SWT.MOD1 | 'd'); responds only to cmd-shift-d, both showing correct glyphs in the menu item. I tried SWT.KEYCODE_BIT with the actual keycode, but that also responds to both cmd-minus and cmd-underline. Reproducible: Always Steps to Reproduce: 1.Load Snippet29 2.Substitute the accelerators cited above. 3.Observe results in Output window.
Taking this, but may not make it for 3.6.
Curiously, if you have two separate menu items, with one that specifies cmd-'-' and the other cmd-shift-'-' they work correctly. And, cmd-shift-'-' by itself works as expected. But cmd-'-' alone responds to cmd-'-' and cmd-shift-'-'. AWT does not have this problem, which I find odd. The accelerator handling is pretty much identical.
Created attachment 167795 [details] Fix There are situations where command-<char> and command-shift-<char> map to the same menu accelerator (mainly when there's no clear lowercase/uppercase mapping). Guard against that by seeing what accelerators were pressed to invoke the action and if they don't match the accelerator mask, ignore it.
(In reply to comment #2) > AWT does not have this problem, which I find odd. The accelerator handling is > pretty much identical. Ignore this comment -- AWT looks at the key event and determines it is a menu key equivalent before the OS gets a chance. Cocoa never gets involved.
Ready for review.
(In reply to comment #5) > Ready for review. (In reply to comment #3) > Created an attachment (id=167795) [details] > Fix > > There are situations where command-<char> and command-shift-<char> map to the > same menu accelerator (mainly when there's no clear lowercase/uppercase > mapping). Guard against that by seeing what accelerators were pressed to invoke > the action and if they don't match the accelerator mask, ignore it. Thanks for the fix. Are you saying that Cocoa itself does not distinguish the two accelerators unless the shifted version is defined?
(In reply to comment #6) > Are you saying that Cocoa itself does not distinguish the two accelerators > unless the shifted version is defined? Only in cases where the accelerator character doesn't have a lowercase equivalent. For example, if you specify Cmd-'D' as the modifier mask and character, respectively, Cocoa considers that and Cmd-Shift-'d' as equivalent. (note capital vs. lowercase) In your example, the lowercase of '-' is also '-', so cmd-'-' and cmd-shift-'-' are identical if you only have cmd-'-' in the menu. But if each one is in its own menu item Cocoa will map the key combo and accelerator to the right menu item.
This problem only happens on Snow Leopard. Current code works fine in Leopard. It looks like a bug introduced by Apple. We should consider putting a version check if we decide to workaround it. It might be better to open a radar bug instead. The fix has one problem. 1) Run snippet 2) Pulldown menu using mouse 3) Use arrow key to select menu item 4) Press and hold Ctrl key 5) Select menu item by pressing Return key You get no selection event. The problem will happen any time the current event is a key event, but the menu item is not selected by typing the accelerator key.
(In reply to comment #8) > This problem only happens on Snow Leopard. Current code works fine in Leopard. > It looks like a bug introduced by Apple. We should consider putting a version > check if we decide to workaround it. It might be better to open a radar bug > instead. Sigh. Indeed it is. Given that this is 10.6-only and that having both cmd-shift-'-' and cmd-'-' in the menu work properly I think we should mark this as NOT_ECLIPSE. It's not work working around it. I'll file a bug with Apple.
