bug-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #34764] XIB loading: "Custom class" set in Interface Builder ignore


From: Eric Wasylishen
Subject: [bug #34764] XIB loading: "Custom class" set in Interface Builder ignored
Date: Wed, 28 Mar 2012 20:46:37 +0000
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_3) AppleWebKit/534.54.16 (KHTML, like Gecko) Version/5.1.4 Safari/534.54.16

Follow-up Comment #6, bug #34764 (project gnustep):

Sure, Fred, I'll try to help. I had another look today.

I think we must determine the final class name before instantiating the
object. As you, say there are too many problems with trying to change the
class after decoding it.

For Julain's example, the custom class name is stored in the
flattenedProperties dictionary under the objectID of the IBObjectRecord for
the NSImageView object.

So the problem is: when we are in  -[GSXibKeyedUnarchiver
decodeObjectForXib:forClassName:withID:], we need to be able to look up the
IBObjectRecord which contains the current object; in other words, the
IBObjectContainer needs to be fully decoded.

The tricky thing is controlling the order of decoding. We need to decode the
IBObjectContainer (with the flattened properties, and object records) before
decoding any of the regular objects, but this is not possible since decoding
an object record will trigger decoding the object it references.

The only thing I can come up with is a bit of a hack. We add a flag to
GSXibKeyedUnarchiver, -setDecodesReferencesAsStrings: (BOOL). When this is
YES, calling -decodeObjectForKey: will give you an NSString with the object's
ID, rather than actually decoding it.  Then, we turn on this flag when
decoding IBObjectContainer, so any references from the object container to the
main XIB object graph are just string ID's, and hence the main object graph
will remain undecoded.

As far as I can see this is the only way to do it… I have no idea why the
format is designed like it is. AFAIK Xcode compiles xibs to nibs and AppKit
doesn't load them directly, so Apple can probably with oddities like this more
easily.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?34764>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]