I think I sorta know what some of it means, but I'm not sure about it all.

I think it means NSKeyedUnarchiver had trouble. I think NSKeyedUnarchiver is probably involved in instantiating my nib. The nib involved in the failing operation does, indeed, have an NSDictionaryController. I guess that the fact that the message mentions that (relatively unusual) class means NSKeyedUnarchiver found the nib, and made at least a bit of sense of it all.

But, does this mean "I found your NSDictionaryController, but something's wrong with it and I can't decode it"? That is, something busted inside my NSDC?

Or, does it mean "I know I'm supposed to be looking for an NSDC, but dang if I can find the bugger"? That is, is there a platform version consideration here? The tester with the troubles runs Tiger; I build on Snow Leopard using SDK 10.4u and deployment target 10.4. I haven't heard from any other Tiger testers, troubled or not, so perhaps this is an SL->Tiger versionitis issue? But not-so-very-long-ago builds, from this same configuration, work for this tester, so that seems ruled out. Is Tiger simply not expected to grok Snow Leopard NSDCs?

> But, does this mean "I found your NSDictionaryController, but something's wrong with it and I can't decode it"? That is, something busted inside my NSDC?

No.

> Or, does it mean "I know I'm supposed to be looking for an NSDC, but dang if I can find the bugger"? That is, is there a platform version consideration here? The tester with the troubles runs Tiger; I build on Snow Leopard using SDK 10.4u and deployment target 10.4. I haven't heard from any other Tiger testers, troubled or not, so perhaps this is an SL->Tiger versionitis issue? But not-so-very-long-ago builds, from this same configuration, work for this tester, so that seems ruled out. Is Tiger simply not expected to grok Snow Leopard NSDCs?

It's not expected to grok NSDCs at all. The class documentation states that the class was added in Leopard.

> One of my testers (and, naturally, none of the test systems I can get my hands on) reports this Console error when performing a certain operation:
>
> -[NSKeyedUnarchiver decodeObjectForKey:]: cannot decode object of class (NSDictionaryController)
>
> I think I sorta know what some of it means, but I'm not sure about it all.
>
> I think it means NSKeyedUnarchiver had trouble. I think NSKeyedUnarchiver is probably involved in instantiating my nib. The nib involved in the failing operation does, indeed, have an NSDictionaryController. I guess that the fact that the message mentions that (relatively unusual) class means NSKeyedUnarchiver found the nib, and made at least a bit of sense of it all.
>
> But, does this mean "I found your NSDictionaryController, but something's wrong with it and I can't decode it"? That is, something busted inside my NSDC?
>
> Or, does it mean "I know I'm supposed to be looking for an NSDC, but dang if I can find the bugger"?

It's this one. Well, it means "Hey, I found one, but I don't know how to unpack it."

> That is, is there a platform version consideration here? The tester with the troubles runs Tiger; I build on Snow Leopard using SDK 10.4u and deployment target 10.4. I haven't heard from any other Tiger testers, troubled or not, so perhaps this is an SL->Tiger versionitis issue? But not-so-very-long-ago builds, from this same configuration, work for this tester, so that seems ruled out. Is Tiger simply not expected to grok Snow Leopard NSDCs?

Tiger is (as you note) 10.4/10.4u; NSDictionaryController is tagged as being available in 10.5 (Leopard) and later.

So Tiger's unarchiver doesn't know what to do with an archived NSDictionaryController. There's a setting in Interface Builder which should warn you about this kind of thing - if you're setting the deployment target for the nib correctly then IB should warn you that you're encoding something that 10.4 knows nothing about.

> if you're setting the deployment target for the nib correctly then IB should warn you that you're encoding something that 10.4 knows nothing about.

Ah, swell ... yet one more spot to configure this. With your help, I found "nib info" in IB, with a "Deployment Target" list, currently set to 10.5, and correcting it to 10.4 produces an error, just as you say.

It seems like there ought to be a single central place to set deployment target, is there not? Is the fact that I somehow got mis-matched target settings in Xcode and IB worth a bug report? Bearing in mind that I may not be able to give solid historical info: this project has been under development since OS X 10.2, with multiple tool-chain upgrades, reconfigurations, and the like; I could imagine that some sequences of UI interactions would legitimately reach this confused state, and I certainly couldn't deny doing them.

> On Apr 26, 2010, at 4:34 PM, Chris Parker wrote:
> >> if you're setting the deployment target for the nib correctly then IB should warn you that you're encoding something that 10.4 knows nothing about.>
> Ah, swell ... yet one more spot to configure this. With your help, I found "nib info" in IB, with a "Deployment Target" list, currently set to 10.5, and correcting it to 10.4 produces an error, just as you say.
>
> It seems like there ought to be a single central place to set deployment target, is there not?

That'd be nice. :)

> Is the fact that I somehow got mis-matched target settings in Xcode and IB worth a bug report?

Absolutely. At present, I don't think there's anything automagic happening to keep that in sync. Please file a bug.

> Bearing in mind that I may not be able to give solid historical info: this project has been under development since OS X 10.2, with multiple tool-chain upgrades, reconfigurations, and the like; I could imagine that some sequences of UI interactions would legitimately reach this confused state, and I certainly couldn't deny doing them.

Our tool chain shouldn't be making this sort of thing any harder or more confusing than it already is. It seems completely reasonable to me that if I've set my Xcode project's deployment target to the 10.4u SDK, then the resources I create for that project should track the project.