Unfortunately, the explanation of File's Owner is pretty short at the Apple docs. I know it is an proxy object. But what's really the point about that "File's Owner" object? What is it good for?
+1
A:
http://www.cocoadev.com/index.pl?FilesOwner
In essence, whichever object loaded the NibFile becomes the file's owner for that nib file.
Sören Kuklau
2009-02-28 14:48:31
This is incorrect. See http://crazyviraj.blogspot.com/2009/05/cocoa-what-is-files-owner-in-nib.html
psychotik
2009-10-11 20:13:10
+4
A:
I know it is an proxy object.
It's not. It's a real object. The icon in the nib is a proxy only in the sense that all the other icons represent objects archived in the nib, and the File's Owner isn't. But the FO is not a proxy object in your application.
But what's really the point about that "File's Owner" object? What is it good for?
It's the object that owns the objects in the nib.
That's it. Nothing more to it than that.
Peter Hosey
2009-02-28 14:48:50
Thanks. So all top-level objects in the nib are properties of the File's Owner object? Where is the class from that File's Owner object? Where can I see it?
Thanks
2009-02-28 15:03:37
Select File's Owner in IB, then Command-6. You'll the Class Identity section which will let you set the class for the File's Owner.
sbooth
2009-02-28 16:01:32
Not necessarily. You can have the File's Owner be blissfully unaware of the contents of its nib if you want. This is what outlets are for: telling one object about other objects. You should give the FO at least one outlet to an object in the nib; you'll then hook that up in IB.
Peter Hosey
2009-02-28 16:16:00
As for the class of the File's Owner: You set File's Owner when you load the nib; the methods for doing that all have an “owner:” argument, where you pass the object that will be File's Owner. Setting it in IB helps IB show you the right outlets, actions, and bindings when you select the FO icon.
Peter Hosey
2009-02-28 16:19:01
+3
A:
It's easier to understand the meaning of the File's Owner reference if you read about and understand the nib loading process.
Cocoa's frameworks handle many nib loads automatically on your behalf, with one of Cocoa's own built-in classes serving as the controller class that manages, or "owns" the nib file's instantiated objects. When you load your own nibs manually, you get to choose which class will serve as the file's owner.
When you read about the nib loading process, pay attention to the "owner:" parameter on many of the loading methods. Its exactly this object that will be connected to the objects in your nib file as File's Owner
danielpunkass
2009-02-28 14:53:18
so to sumarize that: The File's Owner is exactly that object which has instantiated / loaded the NibFile, so that the Nib is something like a property of that object. So this object is the creator, so lets say the owner of that NibFile. Right?
Thanks
2009-02-28 15:08:31
That is mostly correct, with the small caveat that an object can load/instantiate a nib file without designating itself as the owner. Since the owner is passed as a parameter to the loading a mechanism, one object could load a nib, hooking up another object as owner.
danielpunkass
2009-02-28 16:09:27
Basically, when you load the nib, you say “load in some objects from here; this object [owner:] owns them.” You can say you own them, or you can say another object owns them; you do that by setting owner: to self or to another object.
Peter Hosey
2009-02-28 16:23:08
And why should another object own them. what is the benefit of owning them?
Thanks
2009-02-28 16:30:46
This is an architectural design question. Some solutions will find an organizational benefit to designing classes that "claim a specific nib themselves" while others would benefit from classes that instantiated objects and tell them which nib to use to do it.
danielpunkass
2009-03-01 02:52:04
+2
A:
Best way to explain it is with an example of how to set it up. Let's say you have an NSWindowController subclass which is a controller for a preferences window. The preferences window is in a NIB called "Preferences".
In your NSWindowController subclass you would have the following init method:
- (id)init {
if (self = [super initWithWindowNibName:@"Preferences"]) {
//do initalisation
}
return self;
}
This initialises the window controller, associating it with the nib named "Preferences" in the application's main bundle. Note that the NIB has not yet been loaded (this will happen when you first call -window on the window controller.
In the Preferences NIB you would then click on the File's Owner icon and then go to the Class Info panel of the Inspector. In here you would set the class to the name of your window controller class (eg PreferencesController). This now represents an instance of your window controller so you can connect up outlets and actions.
While editing in IB it is just a proxy of the object, as with any object you drag to the NIB, but when the NIB is loaded it will be set to the window controller you created.
Martin Pilkington
2009-02-28 16:04:08
+5
A:
Nib files are often referred to as "freeze dried" and ready to run, and they are a great way of making your apps more modular which can reduce memory usage. Nib files can be defrosted, or loaded into memory anytime when the app needs the objects inside it.
Whenever a nib file is defrosted, it needs a pointer to the object that defrosted it. And that object is usually, the File's owner. The File's owner allows objects inside the nib file to access objects that existed before the nib file was defrosted. In a way, the File's owner acts as a bridge between newly loaded objects and old objects.
Earl Claridad
2009-03-11 09:09:44