On Aug 19, 2014, at 00:32 , Daryle Walker <dary...@mac.com> wrote:

> I looked for -runPageLayout: in NSApplication.h, and I couldn’t find it. 
> That’s why I thought this action may be obsolete and unsupported.
> 
> However…
> 
> There are a lot of methods in the HTML docs for NSApplication. I thought the 
> provided -runPageLayout: was a myth, but it’s actually there! I didn’t see it 
> until the fifth re-read. So this base-class version is official. But why 
> didn’t I see it in the header? (And that time I did use Command-F to help.) 
> In the HTML docs, I usually skip over a method’s listed header, since it’s 
> usually obvious. But looking at it this times shows that the method is in a 
> different header! Sure enough, the method is in that header.

The best way to find methods in the Cocoa headers is to use Command-Shift-O. 
Guessing which header file you want is an exercise in frustration.

> So, to have an app-global Page Setup command:
> 
> 1. Either insert an app-global responder, ahead of the application object, to 
> handle the action. I guess the NSDocument system does this.

I don’t think so. TextEdit is a NSDocument-based application, but Page Setup… 
isn’t enabled unless a document is open. In that case, the document object is 
in the responder chain, and so handles the menu item, but there’s nothing 
“app-global” about it.

> 2. Or replace NSApplication with a subclass that implements:
> 2a. -validateUserInterfaceItem:, which must test for the -runPageLayout: 
> action and allow it. (Pass other actions to super.)

I dunno about this. It’s possible that once upon a time Page Setup… was 
generally enabled by NSApplication (I don’t remember), but the TextEdit case 
suggests that it isn’t so now. (I also looked at an old app of my open that 
happens to have Page Setup on the File menu, and it doesn’t get enabled there 
either.) The fact that NSApplication has the action method doesn’t imply that 
NSApplication does anything to enable the menu item.

> 3. Note that you cannot use the application delegate to store the method. The 
> hacks used to consider the delegate a responder don’t include that method 
> and/or the application object goes first and locks out the delegate from 
> providing an override.

This sounds wrong. Keep in mind that two conditions must be satisfied for a 
menu item to be enabled:

a. There must be an object in the responder chain that implements the 
associated action method.

b. *That object* must return YES from validateUserInterfaceItem.

You can’t implement the validation in one place and have the implementation 
somewhere else. If you want to avoid subclassing NSApplication, you could 
implement Page Setup in the app delegate, but you’d have to do both (a) and (b) 
— even if (a) just invoked the NSApplication implementation.

_______________________________________________

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

Reply via email to