On Sun, Oct 20, 2013, at 01:14 PM, Charles Srstka wrote: > 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,
In the default non-document template, ⌘E maps to Edit > Find > Use Selection for Find. > 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. This describes the behavior for key equivalents for disabled menu items as well as key combinations that don't map to menu items. > > 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. This leads me to believe that NSMenu is populating the menu hierarchy once and caching a mapping of key equivalents to menu items. Which is unfortunate, and goes against the implication from the 10.6 AppKit release notes that menus are fully repopulated once per event. So I filed a bug: <rdar://problem/15274535> (NSMenu does not ask its delegate to populate the menu for every key equivalent) If you try to get around this by implementing -menuHasKeyEquivalent:forEvent:target:action:, things get weirder still: - This method is called for every potential key equivalent. This would be useful, except: - Even if you return NO, NSMenu still looks for a menu item with that key equivalent and invokes its action, in direct violation of the documentation for this method. I cannot reconcile this behavior with the documentation or the intended behavior of the frameworks at all, so I filed another bug: <rdar://problem/15274476> (NSMenu performs key equivalent despite delegate's insistence). --Kyle Sluder _______________________________________________ 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
