Le 01.07.2013 10:57, Luboš Doležel a écrit :
On Wed, 26 Jun 2013 01:35:17 -0400, Gregory Casamento wrote:
Lubos,
I'm not sure why you're saying it should only be used for looking
up
the name. What leads you to the conclusion that this is all it's
used for. When I wrote it I did many backtraces to determine how it
worked.
If you have known object A and custom class B. "Known" classes are
classes which IB knows about (e.g. Cocoa classes) and can
archive. A is what is actually archived in the .nib file because
that is what Interface Builder can instantiate and save, but in the
data structures which are saved in the nib, there is a map which
indicates that object A should be replace by an instance of custom
class B. The way this is indicated by the user is when you select
the custom class in the class inspector in IB.
NSClassSwapper is certainly doing what it is supposed to be doing in
this case. The only fault, I believe is what Fred pointed out in
an
earlier email. The cell contents and settings are not being copied
and, perhaps, they should be.
Anyway, just adding my 0.02 to the conversation.
GC
Hi,
in your example, I'd assume that custom class B is a subclass of A.
Meaning an instance of B can be fully treated as an instance of A.
So why not instantiate and unarchive it as class B from the start?
I'm not implying there's anything wrong here, I just don't understand
why it works like that.
Are you sure that from the "interface builder" you have access to the
Custom Class B ?
How could it be instantiated ? Let's say the code is not compiled, how
can you instantiate
something just from its source code ? I am asking but I am not an
expert in this domain...
_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev
