On 2/18/18 23:26, Quincey Morris wrote:
I dunno. I always though of the attributes as something extensible, but I guess they’re not really. (They can’t be, in NSAttributedString is an interchange format between apps.) Looking at the documented list, I would be worried about NSTextAttachment, which isn’t even documented as conforming to NSSecureCoding. Those NSAccessibility… keys don’t look too safe either.
I'm not sure where the NSAccessibility… keys are defined, I looked at NSAttributedString.h they are not there. Anyway...
The saga isn't over yet, I found a workaround for the problem for classes that are not NSSecureCoding compliant:
First I sub-class the offending class, implementing the NSSecureCoding protocol, +supportsSecureCoding and -initWithCoder:. Since it is impossible to safely invoke the non-secure -initWithCoder: version of the class itself, I use a suitable other designated initializer when calling super.
Then I set up the class as substitution for the original in the NSKeyedUnarchiver using -setClass:forClassName:.
Finally I add it to the list of acceptable classes when decoding the attributed string. Works fine for NSShadow, NSTextAttachment and NSCursor. Of course this looses the attributes real values, but those I don't care about anyway. I haven't encountered a cursor attribute yet, though. Regards Markus -- __________________________________________ Markus Spoettl _______________________________________________ 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
