On Oct 20, 2013, at 2:46 PM, "Mills, Steve" <smi...@makemusic.com> wrote:

>> On Oct 20, 2013, at 14:38, "Ken Thomases" <k...@codeweavers.com> wrote:
>> 
>> This isn't correct.  Menus are updated/validated when resolving keyboard 
>> shortcuts.  What makes you think otherwise?  Lots of things wouldn't work if 
>> that weren't so.
> 
> For what it's worth, Cocoa's key equiv updating doesn't always work 
> perfectly. We've had problems here and there that required creative and brute 
> force workarounds. Just a heads-up for those doing non-trivial key equiv 
> management.

I've played around with this a bit more, using the standard Xcode non-document 
app template, and its behavior is actually quite weird.

1. Typing a keyboard shortcut that's connected to one of the items currently in 
the menu works as you would expect. menuNeedsUpdate: gets called each time you 
type the shortcut. Typing ⌘-O repeatedly causes menuNeedsUpdate: to repeatedly 
fire, since the "Open" menu item has that shortcut (even though it's inactive).

2. However, shortcuts that are not connected to any menu item, like ⌘-E or ⌘-R, 
only cause menuNeedsUpdate: to fire the *first* time you type them. After 
you've typed one of them once, typing that shortcut again, *or any other 
invalid shortcut for that matter*, just causes the system to beep, and 
menuNeedsUpdate: is *not* fired.

3. Now here's where it gets weird: Typing ⌘-T of course brings up the Font 
panel like it always does, and causes menuNeedsUpdate: to fire each time it 
does so. *However*, if you type an invalid shortcut like ⌘-E or ⌘-R beforehand, 
subsequently typing ⌘-T will *not* cause menuNeedsUpdate: to fire, and it will 
never fire again for that shortcut until you actually click on a menu to cause 
it to draw.

4. Oddly enough, the keystroke combo ⌘-shift-W seems to have some kind of 
special immunity to this behavior, since it seems to repeatedly cause 
menuNeedsUpdate: to fire regardless of whether another invalid shortcut has 
been pressed. However, I *really* wouldn't want to be relying on this behavior, 
myself, particularly given that the shortcut could theoretically be different 
for different localizations, and could conceivably fall on one of the "update 
once, ignore after" keyboard shortcuts.

5. Validation definitely does *not* fire for unmapped keyboard shortcuts. It 
only fires if the keyboard shortcut in question is already mapped to an item 
that performs an action on the object which called validateMenuItem:, so I 
stand by my statement that validation will not work adequately for this purpose.

Charles

_______________________________________________

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to