A little earlier I wrote... > The Trainer app is where things fall over. It reads the file into > an NSData object and tries to decode it with NSKeyedUnarchiver's > -unarchiveWithData: but this results in: > > *** -[NSKeyedUnarchiver decodeObjectForKey:]: cannot decode object of class > (SplitsTestSet) > > I really don't understand why this is happening. I'm convinced it's > not a problem with library linking, as these apps have no problem > instantiating various objects sourced from the library.
And with that bold claim I immediately stand out to be the complete idiot - it was a linking problem after all... An article I found via Google suggested that if the library included categories, then "-ObjC" should be added to "Other Linker Flags". I'd ruled this out earlier because I didn't have any categories in my library. Except that I did, as class extensions (I had some properties redefined internally as readwrite rather than the public readonly). So that worked. Which raises another question: if that fixed it in my misbehaving app, why is my well-behaved app behaving well given that it *doesn't* have that linker flag set? Could it have anything to do with the fact that the contents of the library were spawned off from that app? Consider these to be rhetorical questions - I'm just happy that I've got over this hurdle and can now move on. Stuart _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
