• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Setting key equivalent for menus depending on window
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • Follow-Ups:
    • Re: Setting key equivalent for menus depending on window
      • From: Kyle Sluder <email@hidden>
    • Re: Setting key equivalent for menus depending on window
      • From: Charles Srstka <email@hidden>
References: 
 >Setting key equivalent for menus depending on window (From: Martin Hewitson <email@hidden>)
 >Re: Setting key equivalent for menus depending on window (From: Andy Lee <email@hidden>)
 >Re: Setting key equivalent for menus depending on window (From: Uli Kusterer <email@hidden>)
 >Re: Setting key equivalent for menus depending on window (From: Martin Hewitson <email@hidden>)
 >Re: Setting key equivalent for menus depending on window (From: Martin Hewitson <email@hidden>)
 >Re: Setting key equivalent for menus depending on window (From: Andy Lee <email@hidden>)
 >Re: Setting key equivalent for menus depending on window (From: Kyle Sluder <email@hidden>)
 >Re: Setting key equivalent for menus depending on window (From: Martin Hewitson <email@hidden>)
 >Re: Setting key equivalent for menus depending on window (From: Kyle Sluder <email@hidden>)
 >Re: Setting key equivalent for menus depending on window (From: Charles Srstka <email@hidden>)
 >Re: Setting key equivalent for menus depending on window (From: Ken Thomases <email@hidden>)
 >Re: Setting key equivalent for menus depending on window (From: "Mills, Steve" <email@hidden>)

  • Prev by Date: Re: Setting key equivalent for menus depending on window
  • Next by Date: Re: Setting key equivalent for menus depending on window
  • Previous by thread: Re: Setting key equivalent for menus depending on window
  • Next by thread: Re: Setting key equivalent for menus depending on window
  • Index(es):
    • Date
    • Thread