Re: NSPageLayout obsolete?
Re: NSPageLayout obsolete?
- Subject: Re: NSPageLayout obsolete?
- From: Kyle Sluder <email@hidden>
- Date: Mon, 18 Aug 2014 19:35:19 -0700
On Aug 18, 2014, at 7:27 PM, Daryle Walker <email@hidden> wrote:
>
>> On Aug 18, 2014, at 1:03 PM, Daryle Walker <email@hidden> wrote:
>>
>>> On Aug 18, 2014, at 12:30 PM, Kyle Sluder <email@hidden> wrote:
>>>
>>> Before you speculate like this, you should try the alternative. -beginSheet… is a drop-in replacement for -runModal. (Just use +[NSPrintInfo sharedPrintInfo].)
>>
>> I added a runPageLayout: action to the window controller, and the menu command was enabled and it worked. I started with the -beginSheet… version, and later used the -runModal call, and both worked.
>>
>> I then added the same action to the app delegate (using -runModelWithPrintInfo:). Worked fine when a window was open, but that still used the window controller version. But when I had no windows, the menu item was disabled, just like my first post! I thought that putting an action in the app delegate (without an explicit validation routine) always enables the corresponding menu item. That’s what happened when I added newDocment: and openDocument: actions after purging the NSDocument code. But that didn’t happen here. Did Apple add an override, or is it a bug? And how can I fix it?
>
> I tried the menu-level validation method in the app delegate. Didn’t work. Is NSApplication somehow blocking this action from going through? (The app delegate gets the actions for new-document and open-document.)
>
> Was going to try the general-level validation method, but I glanced at the web page I had open to the Printing Guide (i.e. I RTFM) and saw:
>
>> When running an app that is not document based, you must override the runPageLayout: method of the NSApplication class. You can also implement the method earlier in the responder chain. If you want to add an accessory view, your runPageLayout: method needs to call the addAccessoryController: method.
My next question was going to determine whether this was the case. ;-)
>
> Would I really have to do the rare NSApplication override? I saw the mention of the responder chain, and thought I could put the app delegate in it. (Although I thought it was already.)
If is, but the delegate comes *after* the NSApplication instance.
> (BTW, since the app delegate usually doesn’t subclass NSResponder, how/why is it part of the responder chain?)
Legacy and convenience. It’s like that on iOS too.
>
> I gave in and made an NSApplication subclass. I added a public override of -runPageLayout: and changed the initial class in the MyApp-Info.plist file. Didn’t work. Changed the class of the Application object of my two XIB files to my new class. Didn’t work. Thinking of overriding -sharedInfo in case the default implementation didn’t pay attention to what I listed as the initial class. Then I tried one last thing: making a general-level validation method (since NSApplication implements that protocol). Got it to work!
Yeah, you have to remember to do both.
Kinda sucks that you have to jump through this hoop, but the subclassing requirement is an artifact of a different era, and obviously works well enough (for the few non-document based apps that use it) that it’s not worth changing.
>
> Then I poked around. I replaced -runModalWithPrintInfo with -runModal after first mistakenly doing NSPrintPanel methods. Then I changed the call to [super runPageLayout:sender] and it worked. NSApplication can do it, but it doesn’t want to. So I took out my override. Everything still works as long as I keep the general-level validation method around.
>
> New Questions:
> 1. Is it safe to depend on the NSApplication version of -runPageLayout: (i.e., only override -validateUserInterfaceItem:)?
I’d say no. Since you have to subclass to implement the validator, providing the correct implementation of the actual action is trivial.
> Otherwise, I would need to override only if I ever added an accessory view.
> 2. Does said message manipulate the shared NSPrintInfo object?
Probably, but there’s no guarantee.
> 3. Would reverting the XIB files’ application proxy back to NSApplication (but keeping my subclass as the app’s initial class) mess anything up?
No, but that sounds like inconvenience for no reason.
--Kyle Sluder
_______________________________________________
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