Resolved app connections & multi nib files: no go?

Discussion in 'Mac Programming' started by zeppenwolf, Aug 26, 2011.

  1. zeppenwolf, Aug 26, 2011
    Last edited: Aug 27, 2011

    zeppenwolf macrumors regular


    Nov 17, 2009
    Is it possible to split up xib files according to the various windows/features an app has? I ask because the applicationWillTerminate() function is never called if I ever open MyPrefsWin, stored in its own xib file... If I just open the app and quit, it works fine.

    Is it necessary to store every darn window of the app in one huge xib?? I really despise running code/loading objects which the user has not specifically required...

    Or if it's possible to split things up, then how do I connect things to make it work? Every MyWindow xib file insists on having its own NSApplication object, and even if I copy the Main Menu to each xib and connect terminate() to the Quit menu item, it still doesn't work.

    I really hate this, and I hope I'm wrong. Thanks for your help.
  2. jiminaus macrumors 65816


    Dec 16, 2010
    Having all your windows in one huge xib is totally the wrong way to go. You have one xib for the main menu and a xib per window (possibly a couple of highly interrelated windows).

    You can change the type of a xib's file's owner to anything you like.
  3. zeppenwolf thread starter macrumors regular


    Nov 17, 2009
    Well I feel better for hearing it. That's what I thought; that's what I've been doing.

    > You can change the type of a xib's file's owner to anything you like

    And that's also what I've been doing. In each case, I have the f's o set to the appropriate controller for the main object of the particular xib.

    But it remains to be explained why appWillTerminate is not called if I ever load the xib for MyPrefsWin; this is the problem.

    How might I debug this, even?
  4. zeppenwolf thread starter macrumors regular


    Nov 17, 2009
    Ok, I found a subview of MyPrefsWin ( the window has panels, each of which are complex enough to deserve their own xib ), wherein the NSApplication objection had its delegate set to File's Owner. Since the F's O was the controller for the specific panel in that xib, the NSApp's delegate was being overwritten with someone who didn't know terminate() from a hole in the ground.

    My bad.

    But I do feel a bit of moral defensiveness here: Why does every xib file insist on having an NSApplication object in it? If an object in a xib file does not add or modify any connections, then we *should* be able to delete it from the file.

    N'est-ce pas?
  5. MrFusion macrumors 6502a

    Jun 8, 2005
    Yep. This week, I found out that an object can even own multiple nib files.
    Until now, for years I thought one instance of e.g. an NSWindowController class owns/controls one xib file.
    But it can own multiple xib files. Even the outlets will work. Just add outlets for both xib files in your subclass, but only use them in the xib that needs it.

    Ain't that cool?

    //load the xib or nib file
    	NSNib *viewNib = [[NSNib alloc] initWithNibNamed:@"CellView" bundle:nil];
    	[viewNib instantiateNibWithOwner:self topLevelObjects:nil];
    	[viewNib release];	
    //obtain the subview via your outlet and add to your main window
    	NSView *aSubView = [[[self mySubView] retain] autorelease];
    	[self addSubview:aSubView];
    //	[self setMySubView:nil]; // in case you want to load the xib file again and get another instance of the subview
  6. chown33 macrumors 604

    Aug 9, 2009
    Sailing beyond the sunset
    The Application object is a proxy object, not a real object instance. File's Owner and First Responder are also a proxy objects.

    See this:

    Look for "proxy" on page.

    As to why a you might want a proxy connection to NSApplication, look at the available target actions, and imagine how you'd do those actions if you didn't have a proxy object.
  7. zeppenwolf thread starter macrumors regular


    Nov 17, 2009
    Chown, thanks for the link. Looks groovy.

    I don't know how I'd do those actions if I didn't have a proxy object. I wouldn't want to try.

    But that's irrelevant. What I suggested was only that if, (meaning, "if and only if"), an object had no connections, then it should be removable:


Share This Page