Re: IB bug? - copyWithZone: selector not recognized
Re: IB bug? - copyWithZone: selector not recognized
- Subject: Re: IB bug? - copyWithZone: selector not recognized
- From: Chris Kane <email@hidden>
- Date: Tue, 27 Aug 2002 19:19:13 -0700
On Tuesday, August 27, 2002, at 03:47 PM, Bill Cheeseman wrote:
on 02-08-27 5:45 PM, James DiPalma at email@hidden wrote:
First, please note that archiving errors are typically bugs in
archiving
code. InterfaceBuilder is not responsible for unarchiving windows at
run
time when your application opens a new document, nor is
InterfaceBuilder
responsible for archiving that window when you save your document's
nib
file from IB.
Some specific problems with archiving can be IB bugs, but my
experience
suggests that 95% of these bugs are not IB bugs. I may be a little
over
sensitive about this issue, but its really just a suggestion and a
hint
about what is happening.
My nib file was created in Interface Builder, so it seems to me that
Interface Builder was responsible for archiving all the items I
created in
Interface Builder.
What Jim is getting at is that IB just creates NSArchivers and
NSKeyedArchivers as anybody can, and just throws the top level nib
object(s) at the archivers and lets them invoke the archiving methods
on the particular objects. So 95%+ of what is going on is code in
Cocoa executing, or people's own classes' archiving/unarchiving. The
same is true on unarchiving -- an NSUnarchiver or NSKeyedUnarchiver is
created by AppKit, and the unarchiver asked to unpack the object(s),
again invoking code of the particular classes.
For the archiving stuff now, IB just either allocates and NSArchiver
and uses that, allocates and NSKeyedArchiver and uses that, or
allocates both and uses them both, depending on the setting, to get the
one or two archive files inside the .nib wrapper. Nothing much
magical. AppKit will only load one of them of course, and 10.2 prefers
the keyed archive file if present, otherwise loads the old archive.
10.1 of course doesn't know to look for the new archive, and ignores it.
One has to be careful when converting occurrences of old
-decodeValueOfObjCType:at:, -decodeValuesOfObjCTypes:, and
-decodeArrayOfObjCType:count:at: methods to -decodeObjectForKey:, if
you've done keyed coding conversion (I missed the first part of this
thread), as the latter gives you an autoreleased object which needs
retaining, unlike the formers. If you've done conversion, you may want
to check over your changes. An "unretained" object would explain
errors like this.
Chris Kane
Cocoa Framework, Apple
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.