views:

73

answers:

2

When I use Interface Builder > Inspector > Bindings to set up an binding for one of my view Items (i.e. an textfield), then I have to specify an object to which this view item will be bound to.

So I am wondering now, what exactly is the job of this object I specify in "Bind to:"? I assume that Interface Builder automatically creates some methods which do all that synchronization stuff. Is that right?

And what does it mean when I "Bind to: File's Owner"? Is that my file with the main-Method inside?

A: 

The object you bind to has to be key value coding and key value observing compatible. Bindings is just a wrapper that use both those technics in a way that results in much less code.

If you really want to know how it works, there's an entry in Mike Ash's blog how KVO works..

I don't know if you want that much details. I suggest that you read the intro to bindings of cocoadevcentral.com. It makes a fairly good job at explaining them.

To your specific question about the File's Owner, Apple writes:

Each Cocoa application has a main nib file that contains the application-specific menus and possibly one or more windows. NSApp is File's Owner of the main nib file. When an application launches, NSApp loads the main nib file, unarchiving it, and displays the menus and initial windows.

Georg
No, the File's Owner is not usually the window controller. If you invoke it directly, it can be, but it's more useful to specify another object (usually self) as owner. NSDocument does exactly this: the document owns the nib's objects.
Peter Hosey
+1  A: 

… what exactly is the job of this object I specify in "Bind to:"?

You bind your view to your controller. The controller owns the model; the controller key you bind to is the name of a property that serves up some part of that model. The model objects have their own properties, and you may (in some cases must) provide a model key path along with the controller key.

I assume that Interface Builder automatically creates some methods which do all that synchronization stuff. Is that right?

Nope. IB never ever creates methods. The Bindings system does all that synchronization stuff, and it already exists. IB just calls it (specifically, it calls the bind:::: method I mentioned in my answer to your other question).

And what does it mean when I "Bind to: File's Owner"?

The File's Owner is the object that owns all the top-level objects in the nib file. The owner of the MainMenu nib is the application object (NSApp). In a document-based application, the document object will load a nib containing the document window; as such, it is the owner of the window, along with any other top-level objects in that nib.

Is that my file with the main-Method inside?

There's no such file, because there's no such method. There is a main function, but it's a function, not a method of an object. There's no object there, so you can't bind to it.

And you can't bind to a file, only an object. The source files disappear* when you link the program into a single executable. The executable contains only classes and functions, and the nibs contain objects (instances of the classes).

If you're asking which file is being owned, it's the nib file (or, more precisely, its contents—but “File's Contents' Owner” is a bit long).

*Well, except for debug symbols, which identify the filename and line number of each instruction.

Peter Hosey
"(specifically, it calls the bind:::: method I mentioned in my answer to your other question)" ... I don't understand this bind method call. Who implements this method which is called?
Thanks
Apple does. It's part of the NSKeyValueBindingCreation protocol, which is part of Application Kit.
Peter Hosey