|
From: | Pierre-Yves Rivaille |
Subject: | Re: NSUnarchiver extensions |
Date: | Tue, 26 Feb 2002 15:58:49 +0100 |
I'm confused as to why you should ever be decoding a GormCustomView. As far
as
I know, it gets encoded into archives as a GSCustomView, so you should always see a GSCustomView in the archive rather than a GormCustomView.
It happens when you drag'n'drop a GormCustomView from the palettes, GormCustomView is encoded and put in the pasteboard then decoded when you drop it on the window.
However, given that for some reason you have managed to get an archive that contains both classes, the decoding class needs to know which class it is replacing, just knowing a version is not enough.
it is not enough, but in this precise case (where, given a version, the encoding is the same for both classes), it is sufficient.
Should return NSNotFound ... fixed. However, this is not actually relevant
to
your problem.
thanks
(The dirty trick solution would be to turn on and off a class variable forGormCustomView before and after loading a nib file, so that it knows when
it
is used to decode a GSCustomView or a GormCustomView.)
That's quick and effective - I wouldn't call it nearly as dirty as changing
the
NSArchiver/NSUnarchiver API, since it's at least local to the one class
needing
it.
Alternatively, how about ...
if ([[aCoder classNameDecodedForArchiveClassName: @"GSCustomView"] isEqual: @"GormCustomView"]) { // decode a GSCustomView } else { // decode a GormCustomView }
I tried this before too, but it was segfaulting too (it is the same problem as before, trying to access info without checking it is nil, I've just corrected it in CVS).
Anyway I just thought that the new methods could prove useful, but I agree i might not be that useful outside tricky situations where other cleaner tricks might also work.
Pierre-Yves
[Prev in Thread] | Current Thread | [Next in Thread] |