John -
I'd like to be able to describe the concept of File's Owner and First
Responder to people clearly. I don't think I would have described it
any differently than Key Thomases did early today. I've copied his
explanation below.
Did you find Ken's explanation helpful?
Jon Hess
On May 23, 2008, at 12:33 PM, Ken Thomases wrote:
On May 23, 2008, at 1:49 PM, Johnny Lundy wrote:
As usual, I can recite the documentation without understanding it :
File's Owner is a proxy object that is set at nib load time to the
object that loaded the nib (I don't know what object loaded my nib,
so that does not help me).
You should know that. Either it's the MainMenu.nib, which is
automatically loaded by the application object (an instance of
NSApplication, by default) or you've made explicit other
arrangements. If you've got a nib other than MainMenu.nib, how are
you arranging for it to be loaded? Whatever the answer to that
question, it tells you what object will be the File's Owner.
In MainMenu.nib, this is the application instance, which is a
shared singleton instance of NSApplication (how all applications
can share this is beyond me),
It's not a singleton across all processes. That's not the meaning
of singleton. A singleton is usually singular only in the context
of a single process. Basically, the process which is your running
application contains one single instance of NSApplication or an
NSApplication-derived class. This object is the File's Owner of
MainMenu.nib.
which is also set to the global variable NSApp (uhh, OK...).
A pointer to that object, the single instance of NSApplication or a
subclass, is stored in a global variable, NSApp. (Again, just to
avoid confusion, "global" within your process, not across all
processes.)
That's all well and good, but what exactly is this thing? Why would
I succeed in having an outlet in my class if I set the Class
Identity of File's Owner to my custom class?
A nib is a collection of interrelated objects freeze-dried into a
file. When you load a nib, you reconstitute the objects within it
and reestablish the connections between them. However, this object
graph would be disconnected from the other objects that already
exist within your application, and so would have very restricted
ability to interact with them. You want a way to connect up the two
object graphs.
So, in your design of your application, you pick some object that
exists prior to the nib being loaded as the connection point -- the
place where the new objects-to-be-loaded will connect up with your
existing objects. Which of your objects you pick is up to you,
although it is often convenient to use an instance of a custom
subclass of NSWindowController or NSViewController.
The nib has a placeholder in the freeze-dried object graph. This is
like a blank spot on a diagram, where arrows point to it, but
there's nothing there, yet. There can also be arrows pointing out
from this blank spot to the other things in the diagram. When your
code decides it's time to load the nib, you specify in that code
that the object you picked in the previous paragraph will be the
nib's owner. The nib loading machinery plops the owner object into
the blank spot in the diagram. It already has existing connections
to your object graph and now, as part of nib loading, the arrows to
and from that blank spot are connected to and from that owner
object. Objects in your nib which had references to the file's
owner get references to that object. Where there were arrows
pointing out from the blank spot, those are outlets from your file's
owner. The nib loading machinery sets the outlets on your owner
object to point to the newly-created objects from the nib.
Now your object graph is integrated, where the new objects have the
references to pre-existing objects which they need to access, and at
least one of the pre-existing objects has a way of addressing the
new objects.
The nib needs to be told the class of your (future) file's owner so
that it can know what outlets it supports. It figures this out by
parsing the .h file which declares that class, looking for the
IBOutlet keyword. You want to set up outlets so that the owner
object has references to the objects that were created by loading
the nib.
Why should I set File's Owner's Class Identity rather than the
Class Identity of a plain NSObject that I drag out of the Library
in IB?
Because that NSObject would not have any relationship to your pre-
existing object graph. There are sometimes good reasons to drag an
NSObject out of the library to instantiate it in the nib, and set
its class to one of your own, and then hook it up to the other
objects in your nib. It's just that this serves a different purpose
than File's Owner.
I hope that helps.
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/jhess%40apple.com
This email sent to [EMAIL PROTECTED]
_______________________________________________
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]
