widget properties

Brian Milby brian at milby7.com
Sat Feb 24 18:56:03 EST 2018

@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).

More information about the Use-livecode mailing list