Image:CocoaNav icon.png

PARMANOIR

Bindings, Outlets, Target+Action across multiple NIBs

When using multiple NIBs, we need a common object that will share data among them. That object will hold bindings, outlets, target/action shared across NIBs. Here we'll use the Application Controller :

Image:MultipleNIBs.gif

How does a NIB work anyway ? Cocoa defines classes (NSWindow, NSTextField), you define classes in your application (ApplicationController, SomeObject). A NIB is a collection of instances of these classes. Adding Windows, custom objects (like ApplicationController), or controllers is just like calling [[SomeClass] alloc] init] — but the NIB will do it for you.

To be useful, these instances must be linked to an existing object — the File's Owner. When loading a NIB, you specify that object as a parameter : [NSBundle loadNibNamed:@"SecondWindow" owner:self].

If you have only one NIB, you don't have to do a thing — loading will be automatic and the File's Owner will be NSApplication. That's how you can link an instance of your ApplicationController to the delegate outlet of File's Owner, which is the running NSApplication.

But if you have multiple NIBs, that owner is your way to share data. Using ApplicationController as owner is like having that blue box in our first NIB — but it has a different name. And you use it just the same : you can bind to ApplicationController's data, define outlets and actions using that File's owner object which is in fact your ApplicationController.

Watch those outlets

If you put your Preferences window in another NIB and define an outlet to it in ApplicationController, it will be initialized only when you load the NIB. Yes, that's obvious for something like the preferences window — but it might not be for whatever else you do. When you load a NIB at runtime, bindings and outlets are setup just then : the first NIB has no idead about the second one.

If you load a NIB multiple times, it will create a new copy of your NIB's objects each time. This is what happens with NSDocument : you get a fresh copy of your window defined in IB. If your NIB defines an outlet to ApplicationController, it will be overwritten with the new copy at each load. Be careful there.

Image:iconZip.png NibRuntimeLoad.zip

Cocoa Bindings

2008 07 25Where in build phases is that file ?
2008 07 192Imagine clickable error messages
2008 07 18Succulent Stormhoek
2008 07 173Loving the for
2008 07 12(Parmanoir) Feed now validates
2008 07 108Telling classes from instances
2008 07 08Comma Trick
2008 07 06Using libffi
2008 07 04BridgeSupport's type and type64
2008 07 042Clickable Disabled MenuItems
2008 07 026Less bugs through compiler optimizations
2008 06 251CocoaNav JS, a light CocoaNav for Safari
2008 06 232NSWindow goodies : bottomCornerRounded, usesLightBottomGradient
2008 06 222Inspecting NSUndoManager's undo stack
2008 06 16Cocoa Regular Expressions via JavascriptCore
2008 06 15Crossing the WebKit bridge
2008 06 08Double and Triple Click
2008 06 05Photoshop-like compositing with Core Animation
2008 06 052One way binding to NSSlider
2008 05 30Threaded Core Animation, Part Deux
Image:rss.png
Image:rss.png

Powered by MediaWiki

Hi ! I'm learning Cocoa to (hopefully !) become an indie developer.

I've written software all my professional life, in C++, PHP, Javascript. I've designed websites and web interfaces. My last venture went into flames as clients were happy but didn't like paying very much.

I've had little luck in the B2B world, I'm hoping for a better future writing Mac applications.

Planet Cocoa