What is the File's Owner (in Interface builder)?

Question

I am new to Cocoa and I don't understand the concept of File's Owner of a .nib file.

Here is the way I would see things :

• Consider a file myNibFile.nib file that describes how a window looks.

• Now, I want to connect an actual window to this .nib file. So, I create a class myWindow, which is a subclass of NSWindowController. And, to do this connection, I change the init method like this:

       -(id)init      {          [super initWithWindowNibName:@"myNibFile"];          return self;      } 

So, I understand that when I create an instance of myWindow, the "system" will go and look at the .nib file and create the adequate object.

So, my question are :

• why do I have to specify that the File's Owner of my .nib file is myWindow ? Isn't it redundant ?

• I guess it means I didn't really understood what the File's Owner. What is it ? Why does the .nib file have to belong to something ? Can't it be "somewhere" in my "application" and when it is needed, the "system" goes there and use it ?

Thanks for helping me to see more clearly in these new concepts !

Answer 1

Two points to be remembered:

• The File owner is the object that loads the nib, i.e. that object which receives the message loadNibNamed: or initWithNibName:.
• If you want to access any objects in the nib after loading it, you can set an outlet in the file owner.

So you created a fancy view with lots of buttons, subviews etc . If you want to modify any of these views / objects any time after loading the nib FROM the loading object (usually a view or window controller) you set outlets for these objects to the file owner. It's that simple.

This is the reason why by default all View Controllers or Window Controllers act as file owners, and also have an outlet to the main window or view object in the nib file: because duh, if you're controlling something you'll definitely need to have an outlet to it so that you can send messages to it.

The reason it's called file owner and given a special place, is because unlike the other objects in the nib, the file owner is external to the nib and is not part of it. In fact, it only becomes available when the nib is loaded. So the file owner is a stand-in or proxy for the actual object which will later load the nib.

Hope you've understood. I'll clarify any of the points if you ask.

Answer 2

The fundamental thing to understand is that Interface Builder allows you to create objects that are automatically connected to each other, with no effort on the part of your program. You can instantiate all kinds of objects including non-view ones, and they can be inter-related; for example, you might create the instance of a table view data source along with the view itself, etc. This mechanism is commonly used to create an Application Delegate within your Main Menu NIB.

However, since it's all done via drag&drop, it seems there is no way that you can form a connection between any of the NIB objects and the objects that already exist in your application, with one exception.

When code is loading the NIB file, you have the option to specify exactly one object which the NIB will consider to be the "Files Owner". This is the placeholder that you see inside Interface Builder; since it can represent any object within your application, Interface Builder can't know what actions/outlets are available on it. This is why you can modify the "class" of the Files Owner, in the Attributes tab.

Files Owner does not really represent "ownership" or "parenthood". What it represents is "the object that loaded this NIB".