On Oct 20, 2013, at 2:02 PM, Kyle Sluder <k...@ksluder.com> wrote:
>> On Oct 20, 2013, at 4:21 AM, Martin Hewitson <martin.hewit...@aei.mpg.de>
>> wrote:
>>
>>
>>> On 20 Oct 2013, at 01:15 am, Kyle Sluder <k...@ksluder.com> 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 (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
