Re: NSPageLayout obsolete?
Re: NSPageLayout obsolete?
- Subject: Re: NSPageLayout obsolete?
- From: Daryle Walker <email@hidden>
- Date: Mon, 18 Aug 2014 22:27:11 -0400
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.
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.) I changed my app-delegate’s base class to NSResponder and, in applicationWillFinishLaunching:, inserted the delegate between the application object and what usually follows it. Didn’t work. Reverted the change. Thought maybe the app delegate should go in front of the app object instead, especially since I’m recalling the app delegate normally responds after the app object, but I decided not to mess with the responder chain anymore.
(BTW, since the app delegate usually doesn’t subclass NSResponder, how/why is it part of the responder chain?)
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!
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:)? Otherwise, I would need to override only if I ever added an accessory view.
2. Does said message manipulate the shared NSPrintInfo object?
3. Would reverting the XIB files’ application proxy back to NSApplication (but keeping my subclass as the app’s initial class) mess anything up?
—
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com
_______________________________________________
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