macOS Identifying File's owner

[mdeh]

Just following along with Apple's documentation.

Her is the setUp.




My question is this. If I make File's owner ( which has the ivars I wish to use) "MyDocument" then the app works as I expect it.

But, **why** is MyDocument the File's owner. ( By this I mean when I bind the value of a text field in IB to the keyPath of the ivar in MyDocument) Is it the fact that MyDocument.h and the nib file are the same name? Sorry is this causes laughter

Or to state it another way, I know that the File's owner is the object that contains the outlets I need to bind to, ( if that is the correct terminology) , but I want to make sure I understand the relationship ( from the diagrams I posted) between MyDocument.Xib and MyDocument.h/m. I choose MyDocument as the File's owner because the name was the same...is this the correct reason?
thanks in advance.

 

[Bakerman]

But, **why** is MyDocument the File's owner. ( By this I mean when I bind the value of a text field in IB to the keyPath of the ivar in MyDocument) Is it the fact that MyDocument.h and the nib file are the same name? Sorry is this causes laughter

In Interface builder, look at the class pane in the inspector for File's owner. An object of this class is instantiated and set as File's owner. This is usually set to MyDocument when you create a new project.

 

[mdeh]

In Interface builder, look at the class pane in the inspector for File's owner. An object of this class is instantiated and set as File's owner. This is usually set to MyDocument when you create a new project.

OK...so this is an arbitrary decision? But, most importantly, I guess, is that it tells one which connections/outlets will be exposed to the various "view" elements at runtime? ( If that makes any sense?) Or...a really dumb question. **Why** choose MyDocument as the File's owner as opposed to some other File? I think part of the difficulty I am having is clearly visualizing in my mind the connection File's owner has with the nib file.

 

[eddietr]

So File's Owner is not an object archived in the Nib or instantiated when the Nib is loaded.

It's just a proxy to an object that will be set at runtime. So what object is it a proxy for? Well, that is up to the object that loads your Nib. Whomever loads your Nib will set the owner either to itself or some other object it is working with.

When you set the "class" of File's Owner in IB, you are not creating an object of that class. Or even guaranteeing that the file's owner will be of that class. All you are doing there is giving IB something to read so it knows what outlets and actions *should* be available on File's Owner when the Nib is actually loaded.

It is very possible that the actual File's Owner may be of a different class than what you specified in IB. In most cases that's a bug in your code or a mistake you made in IB. And in those cases if you connected an outlet of File's Owner in IB and the actual owner does not have that outlet you will get a runtime error.

So that's the general idea of File's Owner. Now specifically in NSDocument, if you do not override the method (makeWindowControllers) that creates window controller(s) for the document, then by default it will create a single NSWindowController.

That NSWindowController asks your NSDocument subclass for a Nib name (windowNibName), and then loads that Nib and sets your document as the owner of that Nib. If you are working from Apple's template for Document based Cocoa app, then you will see there is a windowNibName defined in "MyDocument" that returns the Nib name that is loaded for each document.

 

[eddietr]

mdeh,

Two Apple documents I would recommend you read:

Resource Programming Guide (section on Nibs )
Document-based Applications Overview

Hope that helps.

 

[mdeh]

mdeh,

Two Apple documents I would recommend you read:

Resource Programming Guide (section on Nibs )
Document-based Applications Overview

Hope that helps.

Hi Eddie,
Will look at those when I get home. But, I already conceptualize 2 things that are helpful. The "loader" of the nib file and the concept of "connecting" the contents of the nib file with "real" outlets and actions. That's a good beginning.
Thanks as always.

 

[mdeh]

When you set the "class" of File's Owner in IB, you are not creating an object of that class. Or even guaranteeing that the file's owner will be of that class. All you are doing there is giving IB something to read so it knows what outlets and actions ***should*** (my emphasis added) be available on File's Owner when the Nib is actually loaded.

Having read your suggested documents, I am closer to getting the concept. I am not sure if this was in the documentation, and if it was I apologize. The last part of the conceptual understanding I would like to appreciate is this.

So, given:

An object ( the File's owner)(not to be confused with the proxy File's owner) together with the actual nib file, will at run-time become associated, the control of the loading of these 2 entities being hierarchically superior to both of them....

.... **how** does this loadController ( for want of a better word) ensure it is associating the correct File Owner with the correct nib?

(I am assuming that **I** know what the correct File's Owner is, as I know what actions and outlets I am associating with this particular nib file).

Eddie...if this again does not make too much sense, it's not your lack of explaining, rather my lack of understanding.

 

[eddietr]

.... **how** does this loadController ( for want of a better word) ensure it is associating the correct File Owner with the correct nib?

It doesn't know. Go back again to something I said earlier:

It is very possible that the actual File's Owner may be of a different class than what you specified in IB. In most cases that's a bug in your code or a mistake you made in IB. And in those cases if you connected an outlet of File's Owner in IB and the actual owner does not have that outlet you will get a runtime error.

So look for example at one of the ways an object can load a Nib:

[NSBundle loadNibNamed:@"Some.nib" owner:self]

Whoever is sending that message is saying "load this nib" and I'm the owner. Or that object could specify some other object as the owner. Either way, it may not necessarily be an object of the class you were expecting. If it *is* of the class you expected, it's because you as the programmer made it so. It's not because of any magic happening in the nib loading.

Going back to the example you posted, the WindowController asks your Document object for a nib name. It then loads that nib and associates your document as the owner.

This all happens whenever your app opens a new document. So it is your responsibility to know this and know that in this case the File's Owner will be of your subclass of NSDocument.

And it's also your responsibility to make sure your NSDocument subclass returns the correct nib name.