Re: File's Owner
Re: File's Owner
- Subject: Re: File's Owner
- From: Ken Thomases <email@hidden>
- Date: Fri, 23 May 2008 14:33:19 -0500
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 (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
| References: | |
| | >File's Owner (From: Johnny Lundy <email@hidden>) |