On Sep 12, 2008, at 1:30 PM, Brad Gibbs wrote:
It's disappointing that there's no way to target the instance directly...
By design, an object freezedried in a nib cannot be connected to objects in other nibs, mainly because this would cause loading one nib to load others. If you have to load 1+n nibs in order to resolve all the outlets in one nib, that sortof defeats the purpose of nibs in the first place, which is to allow objects to be decoded piecemeal on demand.
The responder chain is your friend here. Instead of having to bind every last button and widget to a particular object, you just tell it what message to send to the first responder, and when the program runs the widgets automatically act on the thing the user is looking at. For example, the -close: action that the "Close" Menu bar item sends isn't bound to any windows, it just yells "-close:" at the first responder. If the user is in a text field, the text field hears "- close:" and recognizes it as a message it cannot respond to, so it hands it to the next responder, it's enclosing superview. This goes on until "-close:" hits the NSWindow, the final enclosing superview there is, and it DOES know how to handle it, and it takes the appropriate action. "-save:" works the same way, except NSWindows don't respond to "-save:", documents do, so in this case the message is referred all the way back to the NSDocument subclass. "-quit:" gets referred all the way back to your NSApplication, etc.
This is an EXTREMELY powerful part of Cocoa. Your menubar can have a "-checkSpelling:" action and whatever object is in the user's focus at that moment can check it's spelling, all you have to do is make sure that responders that can be spell-checked have a "checkSpelling:" action. The NSColorPanel works by simply sending a "changeColor:" message down the responder chain, and text views, color wells, and other classes all respond to this in appropriate ways. The NSFontPanel works in a very similar manner.
On Sep 12, 2008, at 1:38 PM, Jonathan Hess wrote:
So it sounds like you have two controllers, A, and B, and they each have their own NIB. Sound like you're on the right track. Now you want to have an action in B's NIB affect controller A. Does controller B have an instance variable, or other mechanism, for referencing controller A? If so, you could put an action method on controller B and have that be the target of your button in NIB B. The implementation of that action can then call a method on controller A.
This can work just as well. In your document class, after you've made the window controllers with -makeWindowControllers, hand them both a weak ref to the other, and then use methods on one to pass thru actions to the other.
Jamie Hardt The Sound Department http://www.soundepartment.com/ http://www.imdb.com/name/nm0362504/ _______________________________________________ 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 [EMAIL PROTECTED]
