On Aug 18, 2014, at 1:03 PM, Daryle Walker <dary...@mac.com> wrote:

> On Aug 18, 2014, at 12:30 PM, Kyle Sluder <k...@ksluder.com> 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 (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