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 14:29:38 -0500
On Oct 20, 2013, at 2:02 PM, Kyle Sluder <email@hidden> wrote:
>> On Oct 20, 2013, at 4:21 AM, Martin Hewitson <email@hidden> wrote:
>>
>>
>>> On 20 Oct 2013, at 01:15 am, Kyle Sluder <email@hidden> wrote:
>>>
>>> Rather than rely on intercepting responder chain-based validation, wouldn't it be much easier and more reliable to make some object the delegate of all of your NSMenus and implement -menuNeedsUpdate:?
>>
>> But wouldn’t this object then need to know details about the different windows which are presented in the app in order to decide which shortcut key to set?
>
> No. That's what protocols are for, either formal or informal.
>
> @implementation MyAppDelegate
>
> @synthesize _closeMenuItem, _closeAllMenuItem;
>
> - (void)menuNeedsUpdate:(NSMenu *)menu
> {
> // First, set the default shortcuts in case the main window is unwilling or unable
> _closeMenuItem.keyEquivalent = @"w";
> _closeAllMenuItem.keyEquivalent = @"";
>
> // Let the main window muck with the key equivalents if appropriate
> id mainWindowDelegate = [[NSApp mainWindow] delegate];
> if ([delegate respondsToSelector:@selector(updateCloseMenuItem:closeAllMenuItem:)])
> [delegate updateCloseMenuItem:_closeMenuItem closeAllMenuItem:_closeAllMenuItem];
> }
>
> If you want to be super-fancy, you could take a hint from NSFontManager and send an “update menus” message down the responder chain, but I prefer the simplicity of this approach.
-menuNeedsUpdate: has the same problem that -validateMenuItem: has. It doesn't get called until the menu is about to be actually drawn, which doesn't happen until the user clicks on your menu. This is inadequate for what the OP wants to do, because he is setting keyboard shortcuts, which are supposed to be used without accessing the menu. If the shortcuts aren't updated until the menu is drawn, the keyboard shortcuts will not work at program start, which is irritating. They could also very easily get out of sync with the interface, if the following sequence of events occurs:
1. User clicks on the File menu while there are no tabs open. ⌘-W is mapped to Close Window.
2. User switches to a window that has a bunch of tabs, but never clicks on the File menu, so ⌘-W is still mapped to Close Window.
3. User hits ⌘-W, intending to close one tab. Surprise! He just closed the whole window instead.
Needless to say, this does not provide a good experience to your users.
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