loadNibNamed:owner:

[Simon Slavin]

I'm just learning Cocoa. I seem to be gradually getting
my head around it but it's not easy. So I'm using

[NSBundle loadNibNamed:@"CatList" owner:@"foo"];

in an application which has more than one NIB. What, you
are asking, is '@"foo"' ? Well I'd love to tell you but
I don't know. I completely failed to figure out what I
should be using for the owner. Then I tried 'nil' which
gave an error. So I tried the first non-nil thing that
came into my head and it appears to work, silly though it
is.

But what should I really be using for owner ?

[Michael Ash]

In article <BB704C2B966890F841@10.0.1.3>,
[email]slavins@hearsay.demon.co.uk[/email]@localhost (Simon Slavin) wrote:

> I'm just learning Cocoa. I seem to be gradually getting
> my head around it but it's not easy. So I'm using
>
> [NSBundle loadNibNamed:@"CatList" owner:@"foo"];
>
> in an application which has more than one NIB. What, you
> are asking, is '@"foo"' ? Well I'd love to tell you but
> I don't know. I completely failed to figure out what I
> should be using for the owner. Then I tried 'nil' which
> gave an error. So I tried the first non-nil thing that
> came into my head and it appears to work, silly though it
> is.
>
> But what should I really be using for owner ?

A nib cannot be self-contained, it would be useless if it were. So
you'll notice in Interface Builder, every nib has an object called
File's Owner. That object is not actually part of the nib, it's an
external object that "owns" the nib and its contents. As you may have
guessed, the object you pass to loadNibNamed:owner: becomes the File's
Owner object for the nib file.

So, what do you pass to it? It depends on what you want to do. Normally
you pass self, since typically you're loading the nib for yourself and
not for someone else.

You may also want to make your object a subclass of NSWindowController.
Most of the time when you load a nib it's to get a window on the screen,
which is what NSWindowController is made for. It hides the nib loading
(a little bit) and does a bit of work for you.

[matt neuburg]

In <BB704C2B966890F841@10.0.1.3> Simon Slavin wrote:

> I'm just learning Cocoa. I seem to be gradually getting
> my head around it but it's not easy. So I'm using
>
> [NSBundle loadNibNamed:@"CatList" owner:@"foo"];
>
> But what should I really be using for owner ?

In the nib you'll see a proxy object called "File's Owner". In
loadNibNamed:owner: you are nominating the object who will be that
object. This is usually an NSWindowController but there's no law about
that; the advantage of using an NSWindowController is that it manages
memory better for you when the window closes (it releases everything in
the nib). For this reason, it is more usual for the NSWindowController
to be the one who loads the nib. m.

--
matt neuburg, phd = [email]matt@tidbits.com[/email], [url]http://www.tidbits.com/matt[/url]
REALbasic: The Definitive Guide! 2nd edition!
[url]http://www.amazon.com/exec/obidos/ASIN/0596001770/somethingsbymatt[/url]
Subscribe to TidBITS. It's free and smart.

[Michael Ash]

In article <20030825162405813-0700@news.la.sbcglobal.net>,
matt neuburg <matt@tidbits.com> wrote:

> the advantage of using an NSWindowController is that it manages
> memory better for you when the window closes (it releases everything in
> the nib).

I've seen this claim a couple of times, but I've never been able to find
where it's documented. I also can't see how this would be implemented.
I've never seen a way to automatically get references to all top-level
nib objects without having explicit outlets to them. So, is there any
reference for this behavior?

The closest I can come is this quote from NSWindowController's docs:

"Regardless of who is the file¹s owner, the window controller is
responsible for freeing all top-level objects in the nib file it loads."

This clearly gives the window controller the responsibility, but it
doesn't state that it's done for you. My reading of it is that it
implies your custom NSWindowController subclass is responsible for
having code that releases these objects. But I could be wrong.

[John C. Randolph]

Michael Ash wrote:

>
> In article <20030825221519446-0700@news.la.sbcglobal.net>,
> matt neuburg <matt@tidbits.com> wrote:
>

> > From WinControllersAndNibs.html: "The window controller automatically
> > keeps track of these objects when it loads the nib file, and then
> > releases them when the window controller is deallocated." To see how
> > that's possible, think about what a nib is. m.

>
> Ok, neat. I even went through the trouble of writing a test app for
> this. I added a bunch of extra top-level objects to a nib and had an
> NSWindowController manage it. No leaks as reported by 'leaks', and if I
> manually released one of them and then released the window controller,
> my app crashes.
>
> I still don't see how it works, though. I mean I can understand if Apple
> uses some private APIs to get the work done, but you seem to be saying
> otherwise. I did some research a while ago to see if there was a way to
> get at the top-level objects in a nib without having explicit outlets to
> them, and I never found a way. So any light you could shed on this would
> be nice.

NSWindowController uses -loadNibFile:externalNameTable:withZone: instead
of the simpler -loadNibNamed:owner: method. That way, it's able to
capture more of the information that the Interface Builder stores in the
nib file, such as the list of top-level objects.

Check out NSNibLoading.h, and the NSBundle documentation.

-jcr

[John C. Randolph]

Michael Ash wrote:

>
> In article <20030825221519446-0700@news.la.sbcglobal.net>,
> matt neuburg <matt@tidbits.com> wrote:
>

> > From WinControllersAndNibs.html: "The window controller automatically
> > keeps track of these objects when it loads the nib file, and then
> > releases them when the window controller is deallocated." To see how
> > that's possible, think about what a nib is. m.

>
> Ok, neat. I even went through the trouble of writing a test app for
> this. I added a bunch of extra top-level objects to a nib and had an
> NSWindowController manage it. No leaks as reported by 'leaks', and if I
> manually released one of them and then released the window controller,
> my app crashes.
>
> I still don't see how it works, though. I mean I can understand if Apple
> uses some private APIs to get the work done, but you seem to be saying
> otherwise. I did some research a while ago to see if there was a way to
> get at the top-level objects in a nib without having explicit outlets to
> them, and I never found a way. So any light you could shed on this would
> be nice.

NSWindowController uses -loadNibFile:externalNameTable:withZone: instead
of the simpler -loadNibNamed:owner: method. That way, it's able to
capture more of the information that the Interface Builder stores in the
nib file, such as the list of top-level objects.

Check out NSNibLoading.h, and the NSBundle documentation.

-jcr

[matt neuburg]

In <20030825221519446-0700@news.la.sbcglobal.net> matt neuburg wrote:

> In <mail-51F740.18571525082003@localhost> Michael Ash wrote:

>> In article <20030825162405813-0700@news.la.sbcglobal.net>,
>> matt neuburg <matt@tidbits.com> wrote:
>>

>>> the advantage of using an NSWindowController is that it manages
>>> memory better for you when the window closes (it releases everything
>>> in the nib).

>>
>> I've seen this claim a couple of times, but I've never been able to
>> find where it's documented. I also can't see how this would be
>> implemented. I've never seen a way to automatically get references
>> to all top-level nib objects without having explicit outlets to
>> them

>
> From WinControllersAndNibs.html: "The window controller automatically
> keeps track of these objects when it loads the nib file, and then
> releases them when the window controller is deallocated."

Plus: "Note that NSWindowController automatically releases its nib
file's objects for you." That's in NibFileLoaded.html. So I would
describe this feature as well and truly "documented", and not just a
"claim". m.

--
matt neuburg, phd = [email]matt@tidbits.com[/email], [url]http://www.tidbits.com/matt[/url]
REALbasic: The Definitive Guide! 2nd edition!
[url]http://www.amazon.com/exec/obidos/ASIN/0596001770/somethingsbymatt[/url]
Subscribe to TidBITS. It's free and smart.

[Michael Ash]

In article <3F4B1FDC.CF668EE9@nospam.idiom.com>,
"John C. Randolph" <jcr@nospam.idiom.com> wrote:

> NSWindowController uses -loadNibFile:externalNameTable:withZone: instead
> of the simpler -loadNibNamed:owner: method. That way, it's able to
> capture more of the information that the Interface Builder stores in the
> nib file, such as the list of top-level objects.

Is there any documentation on how this works? The docs for that method
just say that the name table is a dictionary that contains keys like
"NSOwner". I take it there are other useful keys, are they listed
anywhere?

[John C. Randolph]

Michael Ash wrote:

>
> In article <3F4B1FDC.CF668EE9@nospam.idiom.com>,
> "John C. Randolph" <jcr@nospam.idiom.com> wrote:
>

> > NSWindowController uses -loadNibFile:externalNameTable:withZone: instead
> > of the simpler -loadNibNamed:owner: method. That way, it's able to
> > capture more of the information that the Interface Builder stores in the
> > nib file, such as the list of top-level objects.

>
> Is there any documentation on how this works? The docs for that method
> just say that the name table is a dictionary that contains keys like
> "NSOwner". I take it there are other useful keys, are they listed
> anywhere?

I'm not sure if it's documented in Jaguar, but there are only two keys,
and they are @"NSOwner", and @"NSTopLevelObjects".

-jcr

[Michael Ash]

In article <3F4BD0A4.64BCAB0A@nospam.idiom.com>,
"John C. Randolph" <jcr@nospam.idiom.com> wrote:

> I'm not sure if it's documented in Jaguar, but there are only two keys,
> and they are @"NSOwner", and @"NSTopLevelObjects".

Ah, very good, thanks JCR.

[Simon Slavin]

In article <mail-842CEE.17333525082003@localhost>,
Michael Ash <mail@mikeash.com> wrote:

>So, what do you pass to it? It depends on what you want to do. Normally
>you pass self, since typically you're loading the nib for yourself and
>not for someone else.

Ah. Okay, I'll use 'self'.

I think that in my case it probably doesn't matter since the
..nib is part of my application only (not shared) and I don't
need to unload it. I was just confused as to why I got away
with giving it an owner of @"foo".

Thanks to everyone who responded.

[Michael Ash]

In article <BB72F0E8966811BDE4@10.0.1.2>,
[email]slavins@hearsay.demon.co.uk[/email]@localhost (Simon Slavin) wrote:

> I think that in my case it probably doesn't matter since the
> .nib is part of my application only (not shared) and I don't
> need to unload it.

You may not need to unload it, but you need to give it an owner if you
want to get access to any of the objects inside. You may not need that
either if the nib contains a self-contained controller object, but
usually that's bad practice. Generally what you want to do is make your
self-contained controller object be the owner (and subclassed from
NSWindowController). But there is nothing really wrong with another
approach if it works for you, but generally doing things the "right" way
results in cleaner, more flexible code.

> I was just confused as to why I got away
> with giving it an owner of @"foo".

The purpose of being an owner is so you can have outlets hooked up to
you to get access to the contents of the nib. If you have no outlets
hooked up, then nothing will happen involving the owner. If you do have
outlets, ObjC is smart enough that it can ask the owner if it really has
the outlet that the nib claims it has, and so it can gracefully recover
if it turns out the owner doesn't match what the nib says. But still,
don't do this. :P

[Simon Slavin]

In article <BB72F0E8966811BDE4@10.0.1.2>,
[email]slavins@hearsay.demon.co.uk[/email]@localhost (Simon Slavin) wrote:

>Michael Ash <mail@mikeash.com> wrote:
>

>>So, what do you pass to it? It depends on what you want to do. Normally
>>you pass self, since typically you're loading the nib for yourself and
>>not for someone else.

>
>Ah. Okay, I'll use 'self'.

So I tried it and it makes my NIB do stupid things. For
instance, as soon as one of the windows is displayed it's
shown twice with one of the two being immovable. So I
went back to @"foo" which works perfectly.

[Simon Slavin]

In article <mail-1D1534.20574029082003@localhost>,
Michael Ash <mail@mikeash.com> wrote:

>Read about nib loading and how it works, understand what outlets are and
>how they're connected at runtime, and what File's Owner really means.
>Also, it's very rare that you actually need to call loadNibNamed:owner:
>yourself. Most of the time you're better off subclassing
>NSWindowController and letting it handle the dirty work for you.
>
>This approach may work for you, but I really don't recommend that you
>rely on it.

My nib works. The things in it work. It doesn't have any
windows in and the things in it are not related to any
particular window. I could simulate that, I suppose, by
making an invisible window but it doesn't really suit what
the application is doing.

[Michael Ash]

In article <BB7984C09668132616@10.0.1.2>,
[email]slavins@hearsay.demon.co.uk[/email]@localhost (Simon Slavin) wrote:

> In article <mail-1D1534.20574029082003@localhost>,
> Michael Ash <mail@mikeash.com> wrote:
>

> >Read about nib loading and how it works, understand what outlets are and
> >how they're connected at runtime, and what File's Owner really means.
> >Also, it's very rare that you actually need to call loadNibNamed:owner:
> >yourself. Most of the time you're better off subclassing
> >NSWindowController and letting it handle the dirty work for you.
> >
> >This approach may work for you, but I really don't recommend that you
> >rely on it.

>
> My nib works. The things in it work. It doesn't have any
> windows in and the things in it are not related to any
> particular window. I could simulate that, I suppose, by
> making an invisible window but it doesn't really suit what
> the application is doing.

Well, what is the point of your nib if it doesn't have any windows in
it? Normally nibs are for windows, or possibly raw NSViews without
windows. If you just have a bunch of random objects in a nib, why not
instantiate them in code?

Anyway, feeding @"foo" as the owner is wrong. It may work, I'm not
arguing with that. But there are a lot of ways to get things done in
Cocoa, but most of them end up being very painful. What I mean by this
is they work fine now, no problem, and then you find you want to change
things. Or add them. You want two windows instead of one. You want to
use this code in another program. And this is when the difference hits;
if you're doing things the "right" way you'll know because it takes you
three minutes to make the new stuff work. Otherwise you're in a world of
pain.

You are of course free to do whatever you want. But that doesn't change
that your approach is simply covering up the symptoms of whatever is
wrong with your program, and that you really should fix it.