On Jan 16, 2010, at 22:08, Jon Buys wrote: > Well, before this goes any further, I'm going to go ahead and answer my own > question here. > > The problem is that in the code below, I'm actually instantiating two > AppController objects, one in each NIB. So, one AppController doesn't have > any idea about the other AppController, and can't get to it's string. > > The solution I've come up with is to replace my window controller class with > a simple call to NSBundle to load the NIB, setting AppController as the owner > of the second NIB. Then, in IB, I set the identity of File's Owner to > AppController, delete the NSObject, and bind the button to the IBAction in > the File's Owner. > > It's great to solve my own problems, I just wish I'd do it before sending out > to Cocoa-Dev for help!
Well, your solution may be functional, but there's an easier way -- one that leverages standard behavior. There are two parts to this. The first is to instantiate your singleton AppController object in just one nib file. A good place for this is MainMenu, since you have only one of those. The trick is to connect the Application pseudo-object's "delegate" outlet to your AppController object. Then in *any* nib file whose contents need to bind to the AppController object, you can refer to Application.delegate (since the Application pseudo-object is available in any nib file, and it always refers to the same object, so its "delegate" property always refers to your AppController singleton.) That takes care of bindings, typically. However, although you said "bind" above, you likely meant "connect", since bindings are made to a property, not to an IBAction method. For target/action connections, you connect the "selector" outlet (in the Sent Actions section of the "Connections" tab) of your buttons or other controls to First Responder in their own nib file, and choose the appropriate AppController selector from the list. Because your AppController is the application's delegate it is therefore in the responder chain, and -- assuming nothing else implements the same selector -- the action will get routed to your AppController without doing anything clever to the nib file's owner. Note that the list of selectors available for the First Responder pseudo-object is an amalgamation of all the IBAction methods known in your Xcode project's header files. So long as you put your AppController IBAction prototypes in your AppController.h file, IB will synchronize with Xcode and know they exist. Note also that changing a window nib's File Owner from a NSWindowController (or a NSDocument, which has similar behavior wrt the nib file) to some other class is not a good idea. NSWindowController, NSDocument and NSViewController all have built-in functionality to manage the ownership of top level nib objects. If your replacement doesn't have similar functionality, you will either leak nib objects or crash with memory management errors. _______________________________________________ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
