[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug #34764] XIB loading: "Custom class" set in Interface Builder ignore
From: |
Fred Kiefer |
Subject: |
[bug #34764] XIB loading: "Custom class" set in Interface Builder ignored |
Date: |
Fri, 30 Mar 2012 20:02:11 +0000 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20100101 Firefox/11.0 |
Follow-up Comment #8, bug #34764 (project gnustep):
Thank you to both of you for your ideas. I am sure that we will crack this, if
we work together on it. Your ideas may already be partial solutions here. But
as usual things are a bit more difficult. The objects we try to decode show up
at least in two places in the XIB file. One is the IBObjectContainer (key
"IBDocument.Objects") and the other the NSMutableArray (key
"IBDocument.RootObjects"). The later is far better suited for decoding, as
objects show up here in a top down order. But only in the former do we have
the flattened properties.
I think we should change the decoding order around. Get the IBObjectContainer
first, but try not to decode the objects for IBObjectRecords. Maybe just get
the flattenedProperties and the half decoded objectRecords. For these we would
try to extract the id of the object, this is mostly stored as a reference, but
in rare cases we have real objects as well.
We would then loop over all these IBObjectRecords and see whether we have some
properties for an objectID. In that case we store these in the decoder for the
id.
Hmm, thinking all this over, it seems easier to me to do the whole decoding
twice.
In loadModelData:externalNameTable:withZone: we could create a decoder, get
the flattened properties (plus the ids of the objects they belong to) from it
and throw it away. Then we create another decoder, set up the properties there
and do the real decoding.
This may be a slower solution, but seems a lot cleaner to me, as we don't have
to fiddle around with too much decoder internals.
As far as I see the only property we are currently interested in is the custom
class name, we could handle that in the method
decodeObjectForXib:forClassName:withID:
What do you think about this approach?
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?34764>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/