@Ali... I’ve been mulling over the very idea of extending the export mechanism. What I would propose is to add an $object key that would contain the engine related things required to recreate the widget. The same could be done for any LC object (using $kind to identify the classic control/object type or possibly just “classic control”). Possibly more than one additional key. In theory, you could export a whole stack as an array this way.
The export code currently just processes widgets, but a modification there would not be that difficult. The functions used to load/save an object would need mirror functions to load/return an array. Once that is done, things higher up would need similar treatment (card/stack). I just have not had the time to sit down and try to implement my thoughts. > The VCS-related use case for an expanded properties property still exists > though, as far as I can tell, although 'properties' is kind of a bad name > for it. Actually I think it might be better to add 'export' syntax for > classic controls. The nice thing about the export syntax is that you get > exactly the distinct pieces of information required to reconstruct the > widget (according to the widget author's implementation). It might actually > be a completely distinct representation of the widget state than that > provided by a list of properties and their values (although in practice, > it's usually a subset of the properties). > _______________________________________________ use-livecode mailing list firstname.lastname@example.org Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode