CODEWITHSUNDEEP
objective-cxcodecocoaxibiboutlet
Dr.Kameleon
Dr.Kameleon

Reputation: 22810

Connecting actions works. Connecting outlets doesn't

I have a XIB file with my controls in it, loaded in the Interface Builder (Xcode 4.0.2 on Snow Leopard).

The file's owner is set to, let's say, the someClassController class, and I've also added (in the Interface Builder) an NSObject instance of someClass, as well.

I've managed to link e.g. a button with an action in someClassController or someClass - and it works for both of them.

However, whenever I link an outlet to ANY of them, it fails to show up; and NSLog reports NULL pointers.

Upvotes: 1

Views: 185

Answers (2)

paulmelnikow
paulmelnikow

Reputation: 17208

To add to Peter Hosey's answer, and after reading some more details in the other question you posted about this issue, here are some other factors to consider:

  1. The File Owner class selected in the nib is completely ignored at runtime. It's there only for design-time convenience – for checking available actions and outlets.
  2. Is there any chance you're finding nil pointers in -init? Outlets are connected after -init and before -awakeFromNib. They'll never be connected in -init.

I'm trying to understand the sequence of initialization (from your other post). It sounds like you are creating a new instance of your CTTabContents subclass, and passing it to your CTBrowserWindowController subclass's -addTabContents: method. Then the CTBrowserWindowController loads your objects from the nib.

Or, maybe that's wrong. You might be creating a instance of your CTTabContentsController subclass. Then that object is loading TabContents.xib.

It's important to track down where the nib is being loaded and which object is being provided as the file owner at that time.

Another question: are you using manual release/retain, automatic reference counting, or garbage collection?

Finally, I reiterate the importance of printing out the self pointer in your initialization methods. In addition to -init and -awakeFromNib, try other initialization methods like your CTTabContents subclass' -initWithFrame:. When you're discovering intermittent null pointers in the rest of your debugging, print out the self pointers then, too. You'll probably be seeing different values of self then, too.

Upvotes: 1

Peter Hosey
Peter Hosey

Reputation: 96323

When you see problems like this, it's almost always because you have more than one object of the kind that has the outlet. The one in the nib whose outlet you connected is not the one that is examining its outlet.

To investigate this, add statements in the object's initializer method(s) and possibly awakeFromNib to log the value of self.

Some (or all, or none) of the objects may be created in nibs, and some (or all, or none) of them may be created in code; objects in the latter group won't trip awakeFromNib, since they didn't.

Either way, once you've inventoried what instances of the class you have, you can kill them off until you're left with the ones you want.

Upvotes: 3

Related Questions