Re: Newb: Targeting an instance of a class instantiated by a NIB file
Re: Newb: Targeting an instance of a class instantiated by a NIB file
- Subject: Re: Newb: Targeting an instance of a class instantiated by a NIB file
- From: Jamie Hardt <email@hidden>
- Date: Fri, 12 Sep 2008 14:04:19 -0700
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 (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