site_archiver@lists.apple.com Delivered-To: Pro-apps-dev@lists.apple.com User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; nb-NO; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 Thank you Eryk. Best regards, Kristian Harms Kristian, From the link you gave it is clear you had Paul's response; that should be the right thing to do. I agree the uudecode shouldn't have a problem. The string of bytes that NSKeyedUnarchiver mentions in the error is the string 'bplist00' (i.e. the start of a binary plist). I believe keyed archives are stored using plists these days, so that seems right. Perhaps you've messed up the length of the data? It's probably complaining because it's having a failure reading the plist (qua plist). -eryk On Apr 26, 2010, at 12:15 PM, Kristian Harms wrote: Hi, I'm doing something similar to what Steve Christensen asked about in this email to the list, a year ago: http://lists.apple.com/archives/Pro-apps-dev/2009/Feb/msg00036.html In brief, I want to grab from the FCP XML the parameter value for any custom parameters in my FxPlugs and deserialise them. However, when I come to the point where I instantiate the NSKeyedUnarchiver with my NSData, which I have uudecoded based on the string I acquire from the XML, I actually get an Objective-C exception, of type NSInvalidArgumentException, and with reason: *** -[NSKeyedUnarchiver initForReadingWithData:]: incomprehensible archive (0x62, 0x70, 0x6c, 0x69, 0x73, 0x74, 0x30, 0x30) This happens on the init call itself, and not on the [unarchiver decodeObject] call that the link above recommends doing next. I'm stumped as to how to procede. There are no obvious things I've done that could compromise the data -- the only point where a character encoding is involved is when I extract the char* from the NSString holding the uuencoded data, but uuencoded data should be representable as 7-bit ascii anyway, so choosing utf8, latin1 or even ascii should work fine there. There are no character encodings involved after the point where I uudecode. Version info: Running FCP 7.0.2 and plugin compiled using FxPlug SDK 1.2.5, on top of OS X 10.5. -- Kristian Harms _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/evershen%40apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.ap... It was indeed a length-related issue. The NSKeyedUnarchiver's init no longer throws. Regarding the uuencoding, am I right in guessing you have rolled your own implementation? The reason is that it doesn't seem to have been encoded using any of the uuencoding implementations I have found, which insert a newline at regular intervals in the encoded data. It would be nice if you could document any peculiarities of your uuencode. Den 2010-04-26 11:02 PM, skrev Eryk Vershen: This email sent to evershen@apple.com This email sent to site_archiver@lists.apple.com