Professional Web Applications Themes

loadNibNamed:owner: - Mac Programming

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 ...

  1. #1

    Default loadNibNamed:owner:

    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 ?


    Simon Slavin Guest

  2. #2

    Default Re: loadNibNamed:owner:

    In article <BB704C2B966890F84110.0.1.3>,
    [email]slavinshearsay.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.
    Michael Ash Guest

  3. #3

    Default Re: loadNibNamed:owner:

    In <BB704C2B966890F84110.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]matttidbits.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.
    matt neuburg Guest

  4. #4

    Default Re: loadNibNamed:owner:

    In article <20030825162405813-0700news.la.sbcglobal.net>,
    matt neuburg <matttidbits.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 doented. 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.
    Michael Ash Guest

  5. #5

    Default Re: loadNibNamed:owner:

    Michael Ash wrote:
    >
    > In article <20030825221519446-0700news.la.sbcglobal.net>,
    > matt neuburg <matttidbits.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 doentation.

    -jcr
    John C. Randolph Guest

  6. #6

    Default Re: loadNibNamed:owner:

    Michael Ash wrote:
    >
    > In article <20030825221519446-0700news.la.sbcglobal.net>,
    > matt neuburg <matttidbits.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 doentation.

    -jcr
    John C. Randolph Guest

  7. #7

    Default Re: loadNibNamed:owner:

    In <20030825221519446-0700news.la.sbcglobal.net> matt neuburg wrote:
    > In <mail-51F740.18571525082003localhost> Michael Ash wrote:
    >> In article <20030825162405813-0700news.la.sbcglobal.net>,
    >> matt neuburg <matttidbits.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 doented. 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 "doented", and not just a
    "claim". m.

    --
    matt neuburg, phd = [email]matttidbits.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.
    matt neuburg Guest

  8. #8

    Default Re: loadNibNamed:owner:

    In article <3F4B1FDC.CF668EE9nospam.idiom.com>,
    "John C. Randolph" <jcrnospam.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 doentation 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?
    Michael Ash Guest

  9. #9

    Default Re: loadNibNamed:owner:

    Michael Ash wrote:
    >
    > In article <3F4B1FDC.CF668EE9nospam.idiom.com>,
    > "John C. Randolph" <jcrnospam.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 doentation 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 doented in Jaguar, but there are only two keys,
    and they are "NSOwner", and "NSTopLevelObjects".

    -jcr
    John C. Randolph Guest

  10. #10

    Default Re: loadNibNamed:owner:

    In article <3F4BD0A4.64BCAB0Anospam.idiom.com>,
    "John C. Randolph" <jcrnospam.idiom.com> wrote:
    > I'm not sure if it's doented in Jaguar, but there are only two keys,
    > and they are "NSOwner", and "NSTopLevelObjects".
    Ah, very good, thanks JCR.
    Michael Ash Guest

  11. #11

    Default Re: loadNibNamed:owner:

    In article <mail-842CEE.17333525082003localhost>,
    Michael Ash <mailmikeash.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.


    Simon Slavin Guest

  12. #12

    Default Re: loadNibNamed:owner:

    In article <BB72F0E8966811BDE410.0.1.2>,
    [email]slavinshearsay.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
    Michael Ash Guest

  13. #13

    Default Re: loadNibNamed:owner:

    In article <BB72F0E8966811BDE410.0.1.2>,
    [email]slavinshearsay.demon.co.uk[/email]localhost (Simon Slavin) wrote:
    >Michael Ash <mailmikeash.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 Guest

  14. #14

    Default Re: loadNibNamed:owner:

    In article <mail-1D1534.20574029082003localhost>,
    Michael Ash <mailmikeash.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.


    Simon Slavin Guest

  15. #15

    Default Re: loadNibNamed:owner:

    In article <BB7984C0966813261610.0.1.2>,
    [email]slavinshearsay.demon.co.uk[/email]localhost (Simon Slavin) wrote:
    > In article <mail-1D1534.20574029082003localhost>,
    > Michael Ash <mailmikeash.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.
    Michael Ash Guest

Similar Threads

  1. owner's name of a file
    By Josimar Nunes De Oliveira in forum PERL Beginners
    Replies: 2
    Last Post: October 2nd, 09:19 PM
  2. Uploads and file owner
    By Pertti Kosunen in forum PHP Development
    Replies: 6
    Last Post: September 7th, 05:33 PM
  3. Changing The owner of the Computer
    By Yolanda Giles in forum Windows Setup, Administration & Security
    Replies: 3
    Last Post: July 6th, 04:32 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139