On Aug 13, 2009, at 9:32 PM, Michael de Haan wrote:
On Aug 13, 2009, at 6:36 PM, Ken Thomases wrote:
An outlet is a property of an object. It's often backed by an
instance variable as its implementation.
Once you connect an outlet to an object in the nib, this connection
is recorded as data within the xib/nib. Later, when that nib is
loaded, Cocoa's nib loading machinery reestablishes the connection
by setting the property on the object. In this case, the outlet is
on File's Owner which, during nib design, is a proxy for an actual
object which is supplied when the nib is loaded. It's the property
on this actual object which gets set during nib loading.
So, after that nib is loaded, the aboutWindow property of your
AppController object has been set to refer to the panel that was
reconstituted from the data in the nib.
I think I finally get "File's owner" :-) So, if I understand you
correctly, having set File's owner to the appropriate class ( in
this case AppController) I set the appropriate **proxy** outlet of
File's owner to the object ( in this case NSPanel instance) and
when the Nib is loaded, AppController's IBOutlet gets set to the
NSPanel instance, allowing me to send a message from AppController
( set title etc) during run-time.
Correct, although I would apply the word "proxy" to File's Owner
itself, not its outlets.
I like to explain File's Owner like this: imagine drawing the contents
of a nib as an object graph on a piece of paper. There would be
circles for each object (window, view, menu bar, etc.) in the nib,
with labeled arrows coming out of them and pointing to other circles/
objects for connections. Some of these arrows would represent
outlets, others would represent the action of a control. Outlets
would point to whole objects, actions would point to a named selector
(method) within the target object.
Some of the objects in this graph are proxies. They would be
represented by ghostly circles, perhaps with a light gray, dashed
circumference. These objects are not really in the nib. They serve
as empty sockets for objects which will be supplied/found during nib
loading. Without such a way to represent objects which exist outside
of the nib, there would be no way for the objects within the nib to
have connections to the outside world. They would be entirely insular.
Interface Builder provides proxies for the File's Owner, First
Responder, and the Application object. Actually, First Responder is
really a stand-in for the nil target for actions. When a nib is
loaded, an owner object is explicitly supplied to the load method.
The application object is the NSApp global.
You can imagine that at load time, there's an existing graph of real
objects in your program, interconnected in complex ways. The nib
loading process creates a new subgraph for the objects in the nib, but
the subgraph has these empty sockets in it. The loading machinery
grabs the corresponding pre-existing objects and pops them into those
sockets, completing the new subgraph and integrating it into the whole
object graph of your program. In the act of putting a real object
into the socket, any connections to and from the socket in the nib
subgraph are realized with the real object as the destination or
source. Where the real object is now the source of a connection, the
corresponding property on that object has to be set to refer to the
new object that was instantiated in the nib subgraph.
Now, in order for Interface Builder to know which named arrows
(outlets) may come out of these proxy objects, and which action
methods may be targeted within them, you have to tell it what class
they are intended to be. IB communicates with Xcode to learn about
these classes and their outlets and action methods. Xcode learns
about them from the IBOutlet and IBAction tags you supply in your
declarations. (You can actually directly tell IB about outlets and
actions in the Identity Inspector without setting a custom class for
an object, too.)
That's the only role for telling IB about the class of these objects
(and for labeling outlets and action methods in your code). It's not
enforced at load time. You could actually provide a different class
of object at runtime, so long as it provided the necessary outlets and
action methods. (Of course, doing so would be confusing.)
Ken...this may seem like a small thing to you, but this little
exercise, with your help and the others who have answered has given
me some good understanding I did not have before.
Much appreciated.
You're quite welcome. I'm glad I could help. Good luck with your
continued learning. :)
Cheers,
Ken
_______________________________________________
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
