macOS app connections & multi nib files: no go?

[zeppenwolf]

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.

 

[jiminaus]

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.

 

[zeppenwolf]

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

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?

 

[zeppenwolf]

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?

 

[MrFusion]

Is it possible to split up xib files according to the various windows/features an app has?

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

 

[chown33]

But I do feel a bit of moral defensiveness here: Why does every xib file insist on having an NSApplication object in it?

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:
http://developer.apple.com/library/...ual/LoadingResources/CocoaNibs/CocoaNibs.html

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.

 

[zeppenwolf]

Chown, thanks for the link. Looks groovy.

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.

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:

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.