Welcome to the MacNN Forums.

Mac Boy · Jun 18, 2002, 10:22 PM

Ok, here's the deal...

I'm adding an inspector to an app I'm building. Followed pretty closely the method used in Learning Cocoa, except that each of my pane's have their own Controller class, because there are a lot of controls involved, and I wanted to split it up. So basically the Inspector Controller is connected the the pane controllers (which are also Instances in the nib), which in turn are connected to the controls. The views are retained, etc. and display just fine.

The problem is that none of my pane controllers are connected to the controls at runtime, these outlets are always nil. They are connected just fine in IB, and the pane controllers are connected to the Inspector Controller just fine.

I tested (via NSLog) to make sure I wasn't creating multiple instances of the pane controllers accidentally, and I'm not.

The other thing I did was to create an outlet in the Inspector Controller which is connected to one of the controls inside one of the panes, and this one connects just fine and is valid at runtime. It is only the outlets in the pane controllers which are always nil at runtime.

I have rebuilt this part of my program 4 times now, assuming I did something wrong, and I keep getting the same symptoms. I have also reconnected the outlets in IB several times to make sure I am thorough.

What gives?

Much thanks in advance,
- Ross

Brad Brack · Jun 19, 2002, 03:02 AM

<blockquote>quote:<hr />Originally posted by Mac Boy:

The problem is that none of my pane controllers are connected to the controls at runtime, these outlets are always nil. They are connected just fine in IB, and the pane controllers are connected to the Inspector Controller just fine.

I tested (via NSLog) to make sure I wasn't creating multiple instances of the pane controllers accidentally, and I'm not.
<hr /></blockquote>At what point do you check the outlet for a value? These should be set by the time awakeFromNib gets called, but not during the initWithCoder: (which I'm suspecting is where you are checking it?).
Also, if you're not familiar with C, a common problem is doing something like "If (myButton=nil)" instead of "If (myButton==nil)", thus setting the outlet to nil by accident.
Post a snippet of your code- that may help us help you...

seb2 · Jun 19, 2002, 03:42 AM

<blockquote>quote:<hr />Originally posted by Brad Brack:
...
Also, if you're not familiar with C, a common problem is doing something like "If (myButton=nil)" instead of "If (myButton==nil)", thus setting the outlet to nil by accident.
...<hr /></blockquote>this is slightly off-topic, but might be helpful to the one or other.

instead of writing "if (myButton == nil)", make it a habit to write "if (nil == myButton)" -- why?

because if you accidentally forget one of the "="s, you'll get a compiler warning because that's an invalid assignment. it might not be as idiomatic compared to spoken language, but you can avoid lots of headaches that way.

of course, this only works if you're comparing a variable with a constant value and not if you're comparing two variables with one another.

Ghoser777 · Jun 19, 2002, 12:06 PM

I prefer:

<blockquote>code:<hr /><pre style="font-size:x-small; font-family: monospace;">if(!anObject)
{
//oh no! the object is nil! What ever shall I do?
}</pre><hr /></blockquote>My first guess on what's wrong is that you mispelled the name of your outlet in either IB or in your header (or both!). Using IBOulets and IBActions and using IB to make my outlets and actions by reading the header has saved me many headaches.

HTH,
F-bacher

Mac Boy · Jun 19, 2002, 12:13 PM

I am checking for this connection in the awakeFromNib method, at which point the connections are "guaranteed" (from apple's Docs) to be connected. Well... they aren't. Any ideas?

- Ross

Mac Boy · Jun 19, 2002, 12:27 PM

<blockquote>quote:<hr />Originally posted by Ghoser777:
My first guess on what's wrong is that you mispelled the name of your outlet in either IB or in your header (or both!).<hr /></blockquote>I always drag my updated headers into IB after making changes to avoid this problem.

Brad Brack requested code snippets, so here is the header to my Inspector Controller:

<blockquote>code:<hr /><pre style="font-size:x-small; font-family: monospace;">#import <Cocoa/Cocoa.h>
#import "MFConstants.h"
#import "MFObject.h"
#import "MFSelectionManager.h"

#import "MFButtonInspector.h"
#import "MFBorderedBoxInspector.h"
#import "MFImageInspector.h"
#import "MFMovieInspector.h"
#import "MFTextBoxInspector.h"
#import "MFNoObjectsInspector.h"
#import "MFMultipleObjectsInspector.h"

@interface ObjectInspectorController : NSWindowController
{
IBOutlet NSButton *boxLockedBtn;

IBOutlet NSBox *inspectorEnclosure;

IBOutlet NSWindow *inspectorsWindow;

IBOutlet MFButtonInspector *buttonInspector;
IBOutlet MFBorderedBoxInspector *boxInspector;
IBOutlet MFImageInspector *imageInspector;
IBOutlet MFMovieInspector *movieInspector;
IBOutlet MFTextBoxInspector *textInspector;
IBOutlet MFNoObjectsInspector *noObjsInspector;
IBOutlet MFMultipleObjectsInspector *multipleObjsInspector;

id inspectingObject;
MFObjectType inspectingObjectTypeTag;
}

+ (id)sharedObjectInspector;

- (void)updateInspector

NSNotification *)note;

- (void)swapInspectorSubview

NSBox *)inspector;

- (void)switchInspectorObjectType

MFObjectType)tag;
- (id)inspectorForObjType

MFObjectType)type;

@end</pre><hr /></blockquote>And here is one of the pane controllers (they are all very similar):

<blockquote>code:<hr /><pre style="font-size:x-small; font-family: monospace;">#import <Cocoa/Cocoa.h>
#import "MFOBorderedBox.h"

@interface MFBorderedBoxInspector : NSObject
{
IBOutlet NSBox *view;

IBOutlet NSColorWell *borderColor;
IBOutlet NSSlider *borderWidth;
IBOutlet NSColorWell *fillColor;
IBOutlet NSButton *locked;
IBOutlet NSSlider *transparency;

MFOBorderedBox *object;
}

- (NSBox *)view;

- (void)setObjectToInspect

id)_object;

- (IBAction)setBorderColor

id)sender;
- (IBAction)setBorderWidth

id)sender;
- (IBAction)setFillColor

id)sender;
- (IBAction)setLocked

id)sender;
- (IBAction)setTransparency

id)sender;

@end</pre><hr /></blockquote>So the MFBorderedBoxInspector is not connecting to the controls properly (although the controls are being displayed fine, also the target actions are working properly in the interface, so they are not getting prematurely dealloc'ed).

The outlet "boxLockedBtn" in the Inspector Controller is the outlet that connects directly to one of my interface controls, which I used for a test, as I mentioned in my original post. This works fine.

So to recap.... connect from the Nib's file owner, works fine. Connect from another instance in the nib file... nil. Thus, a mystery is born.

Hope this helps a bit.

- Ross

seb2 · Jun 19, 2002, 12:59 PM

<blockquote>quote:<hr />Originally posted by Ghoser777:
I prefer:

<blockquote>code:<hr /><pre style="font-size:x-small; font-family: monospace;">if(!anObject)
{
//oh no! the object is nil! What ever shall I do?
}</pre><hr /></blockquote><hr /></blockquote>you're right, that was a stupid example. in case you want to test for the existance of an object, that's by far the most readable. i was rather referring to comparisons to constants, like "(5 == a)"...

Brad Brack · Jun 19, 2002, 01:35 PM

<blockquote>quote:<hr />Originally posted by Mac Boy:
I am checking for this connection in the awakeFromNib method, at which point the connections are "guaranteed" (from apple's Docs) to be connected. Well... they aren't. Any ideas?
<hr /></blockquote>From the awakeFromNib, are you checking for the object validity of the other instance? That is, in the paneController1's awake from nib, are you looking at objects connected to paneController2? Perhaps it's a timing issue- your paneContoller1 has awoken before paneController2 has finished initializing?
If so, I'm not sure if the instantiation of the nib's objects is multi-threaded, but if it is, perhaps you may have to wait until it is done.

Mac Boy · Jun 19, 2002, 02:24 PM

<blockquote>quote:<hr />Originally posted by Brad Brack:
From the awakeFromNib, are you checking for the object validity of the other instance?<hr /></blockquote>I first noticed something was wrong when my controls weren't getting set to the appropriate values. This turned out to be because they are nil, either at awakeFromNib or any point afterwards.

My test was placing the following code in my MFBorderedBoxInspector class:

<blockquote>code:<hr /><pre style="font-size:x-small; font-family: monospace;">- (void)awakeFromNib
{
NSLog (@"Locked button outlet: %@", locked);
}</pre><hr /></blockquote>and I get the output

<blockquote>code:<hr /><pre style="font-size:x-small; font-family: monospace;">2002-06-19 14:11:31.933 InspectorApp[1963] Locked button outlet: (null)</pre><hr /></blockquote>which is why it seems it's just not connecting, even though everything is set up properly. If I set a breakpoint here, I can again verify that all of my controls (Sliders, Buttons, and Color Wells) are all set to 0x0 while my other outlet, the NSBox which contains these controls, is non-nil.

I was hoping there would be some sort of Catch-22 or bug that somebody else ran into.

It's such a nice day out, but perhaps I will try to create a little Mini-App to recreate this problem, which I can share.

My appreciation to everyone so far.

- Ross

Brad Brack · Jun 19, 2002, 04:13 PM

<blockquote>quote:<hr />Originally posted by Mac Boy:

I was hoping there would be some sort of Catch-22 or bug that somebody else ran into.

It's such a nice day out, but perhaps I will try to create a little Mini-App to recreate this problem, which I can share.
<hr /></blockquote>I just tried adding a couple of windows to my nib plus 2 separate controller classes instantiated in my nib, added NSBoxes to both and an NSButton to both and connected them with IBOutlets of

IBOutlet NSBox *view;
IBOutlet NSColorWell *borderColor;
IBOutlet NSButton *locked;

awakeFromNib gets called for me in both controller classes and

- (void) awakeFromNib{
NSLog(@"Locked: %@",locked);
}

is producing valid addresses even after changing the window settings to a bunch of different values (Retained/Buffered/One Shot/Deferred). Perhaps the nib is corrupt- I'd be curious to see if you could replicate it in a small app- I'll download it and see if I can figure it out if you do.

Mac Boy · Jun 19, 2002, 07:33 PM

<blockquote>quote:<hr />Originally posted by Brad Brack:
Perhaps the nib is corrupt- I'd be curious to see if you could replicate it in a small app- I'll download it and see if I can figure it out if you do.<hr /></blockquote>I figured the same. I completely remade the nib from scratch, without copying or pasting anything, and no dice.

I also made a little sample app, and it worked fine.

I also tried Cleaning all the targets, just in case.

This is aggravating.

Thanks anyway,
Ross

Michel Fortin · Jun 19, 2002, 08:39 PM

I had the exact same problem while making my Gamma Control application. I've tryed everything, including rebuilding the nib, but never solved it or found the cause. I'm using the same preference handling code as in my other application Black Light and there it works. Well, I've decided to use the tag of the elements as a workaround to set the connections programaticaly in my code.

You can download Gamma Control and look at the Preference Panel nib if you want.

Mac Boy · Aug 12, 2002, 03:44 PM

Ok, I've finally found the solution to this problem.

When an IBConnector object is loaded from the nib file, it looks for a method named "setOutlet" where "outlet" is one of your outlet names. It attempts to use this method first to set the object. If you have a function with this same name to serve a different purpose (an Action method, in my case), your outlets will not be set.

For example, if you have an outlet

IBOutlet NSButton *locked;

and a function

-(IBAction)setLocked: (BOOL)lock;

which was intended to be the action for this button. Instead, setLocked is called by the IBConnector to set the object "locked".

To make a long story short, I changed my method to

- (IBAction)setLockedValue: (BOOL)lock;

reconnected the actions in IB, and now everything is working properly.

Just thought I'd share this, as it had been driving me crazy for quite some time. Just goes to show that every problem has an easy solution, it's just a matter of finding it

- Ross

Michel Fortin · Aug 12, 2002, 05:33 PM

Thanks. Same problem solved for me.