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/ _______________________________________________ Bug-gnustep mailing list Bug-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnustep