Sure, but I need a fix, even if temporary. I can probably simply not dearchive that object, but…
I just call -[coder decodeObject:… forKey:…], but the actual object that could be returned is of almost any kind in this particular case. Without decoding it I can’t tell what class it’s going to be, but if I go ahead it crashes before I can tell its class. Catch-22. If I avoid that step altogether it breaks a key piece of functionality in the app. What I need is a way to detect before decoding the object what its class will be. Since the new ‘secure’ decode methods specify the class, presumably they make use of such information. Is there a way I can too? —Graham On 2 Nov 2013, at 4:46 am, Jens Alfke <j...@mooseyard.com> wrote: > > On Nov 1, 2013, at 3:04 PM, Graham Cox <graham....@bigpond.com> wrote: > >> In -initWithCoder for one of my objects, I attempt to decode an >> NSAttributedString. It goes into an infinite recursion and crashes on 10.9. >> This works fine on 10.7 and 10.8. Anyone any ideas what could be going on, > > A bug in CoreText, probably? File a Radar. > > —Jens > _______________________________________________ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
