Re: NSUnarchiver extensions

[Pierre-Yves Rivaille]

> 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 for
> > GormCustomView 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