Re: Setting key equivalent for menus depending on window
Re: Setting key equivalent for menus depending on window
- Subject: Re: Setting key equivalent for menus depending on window
- From: Charles Srstka <email@hidden>
- Date: Sun, 20 Oct 2013 15:14:03 -0500
On Oct 20, 2013, at 2:46 PM, "Mills, Steve" <email@hidden> wrote:
>> On Oct 20, 2013, at 14:38, "Ken Thomases" <email@hidden> 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 (email@hidden)
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:
This email sent to email@hidden