this class is not key value coding-compliant for the key

Question

Hi,

After having spent hours trying to solve a little problem of mine, I come to you for an ultimate try to fix it.

I'm trying to link a UILabel with an IBOulet created in my class. That's something so basic you ask yourself why I need help ?

Everytime I build my application, it crashes on the label screen saying "this class is not key value coding-compliant for the key XXXX".

I know there is tons of messages speaking about that error but I really really couldn't find an answer.

Here is the code in the SecondView.h

@interface SecondView : UIViewController {
    IBOutlet UILabel *string;
}

@property (nonatomic, retain) IBOutlet UILabel *string;

@end

The code in the SecondView.m (Almost nothing in there appart from the auto-generated code - which I don't paste here)

@implementation SecondView

@synthesize string;

And in my SecondView.xib :
- the UILabel is linked with the File's Owner.
- the class of the File's Owner is SecondView

So what is wrong here ????

If you guys want a closer look on my application. You can download it here (it's just a sample one).

http://bit.ly/bUBepA

One last say : every time I create a new application and try to link a UISomething to an IBOutlet, I get the same error. Is there a global param which can generate the error I encounter ?

Thx a lot for your kind help

Guillaume

Answer 1

1. You only need to specify IBOutlet once, the IBOutlet label your ivar is unnecessary.
2. Are you instantiating your NIB using your UIViewController? At some point you should be calling [SecondView initWithNibName:@"yourNibName" bundle:nil];

Answer 2

I downloaded your project.

The error you are getting is

'NSUnknownKeyException', reason: '[<UIViewController 0x3927310> setValue:forUndefinedKey:]: this class is not key value coding-compliant for the key string.'

It is caused by the Second view controller in MainWindow.xib having a class of UIViewController instead of SecondView. Changing to the correct class resolves the problem.

By the way, it is bad practice to have names like "string" in Objective-C. It invites a runtime naming collision. Avoid them even in once off practice apps. Naming collisions can be very hard to track down and you don't want to waste the time.

Answer 3

Thanks so much for your answers! TechZen I'll follow your advice and change my vars names. Kubi,thank you too. These are things you do without knowing it's good or bad. Having that kind of advices is very nice to have.

Answer 4

Another "not compliant" issue I found was when I managed to have two copies of a class for some reason.

I was adding keys to the wrong copy. Interface Builder still saw the keys and let me hook up to them, but at runtime it was using the other copy of the class that didn't have the new keys.

To find which was the "right" copy I used XCode's cmd-click on the class name elsewhere to jump to the correct copy, then I killed off the bad unused copies (after bringing over my edits from the un-used copy first).

Moral of the story: duplicate class files are bad.