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: Martin Hewitson <email@hidden>
- Date: Sat, 19 Oct 2013 22:08:03 +0200
On 19, Oct, 2013, at 08:59 pm, Michael Babin <email@hidden> wrote:
> On Oct 19, 2013, at 1:32 PM, Martin Hewitson <email@hidden> wrote:
>
>> I guess I didn’t understand correctly since my app delegate does not get asked to validate the Close menu item. So far the only thing that get’s asked to validate this is the tabbed window object. Even the window’s delegate is not asked.
>>
>> The documentation states:
>>
>> For document-based applications, the default responder chain for the main window consists of the following responders and delegates:
>> The main window’s first responder and the successive responder objects up the view hierarchy
>> The main window itself
>> The window's NSWindowController object (which inherits from NSResponder)
>> The main window’s delegate.
>> The NSDocument object (if different from the main window’s delegate)
>> The application object, NSApp
>> The application object's delegate
>> The application's document controller (an NSDocumentController object, which does not inherit from NSResponder)
>>
>> My NSPersistentDocument subclass is the main window’s delegate.
>>
>> Clearly my thinking is flawed, but where? If I want the Close menu item to vary depending on the window that is key, and I have to do this with validateMenuItem:, then the responder chain above seems to suggest that I need to have a validateMenuItem: in each and every window in the app. I hope that’s not the case….
>
> https://developer.apple.com/library/mac/documentation/cocoa/Conceptual/MenuList/Articles/EnablingMenuItems.html
>
>> • If the menu item’s target is set, then NSMenu first checks to see if that object implements the item’s action method. If it does not, then the item is disabled. If the target does implement the item’s action method, NSMenu first checks to see if that object implements validateMenuItem: or validateUserInterfaceItem: method. If it does not, then the menu item is enabled. If it does, then the enabled status of the menu item is determined by the return value of the method.
>> • If the menu item’s target is not set (that is, if it is nil—typically if the menu item is connected to First Responder) and the NSMenu object is not a contextual menu, then NSMenu uses the responder chain (described in “The Responder Chain” in Cocoa Event Handling Guide) to determine the target. If there is no object in the responder chain that implements the item’s action, the item is disabled.
>> If there is an object in the responder chain that implements the item’s action, NSMenu then checks to see if that object implements the validateMenuItem:orvalidateUserInterfaceItem: method. If it does not, then the menu item is enabled. If it does, then the enabled status of the menu item is determined by the return value of the method.
>
> Key phrase in both cases: "implements the item's action".
>
> If your Close menu item has an action method of performClose:, then any object (target or in the responder chain) must implement that action method before it will be asked to validate the menu item.
This I understand, but I'm still unclear on the logical route I should take to ensure that my tabbed window's delegate is asked to validate the Close menu but for all other windows the app delegate is asked. Should I then implement performClose: in my app delegate? I can implement it in my document subclass because it can just send the action on to the document window. (I recall actually trying that earlier today but still the delegate was no asked to validate Close, which led me to implement a window subclass to intercept the validation there. If I've understood correctly, the document subclass should get the validation request if it has implemented performClose:, right?)
But what about in the app delegate? Just an empty performClose:?
OK, I'll do some more thinking here and run some more tests to understand the various cases.
Thanks!
Martin
>
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Hewitson
Albert-Einstein-Institut
Max-Planck-Institut fuer
Gravitationsphysik und Universitaet Hannover
Callinstr. 38, 30167 Hannover, Germany
Tel: +49-511-762-17121, Fax: +49-511-762-5861
E-Mail: email@hidden
WWW: http://www.aei.mpg.de/~hewitson
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
_______________________________________________
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