Developing first on android
bobsneidar at iotecdigital.com
Fri Aug 18 18:48:51 EDT 2017
I'll weigh in here. An array representation of a stack might be useful in ways, such as storing it as a property of another stack, or writing it as a binary file to disk as a backup of sorts after arrayEncoding it.
Just so long as no one thinks they can do something like take the key that represents say a button and copy it to another stack array, or a different place in the first array, all will be well. All kinds of nasties happen with ID's and linked graphics and whatnot just copying a button with a linked graphic to another card.
> On Aug 18, 2017, at 15:12 , Brian Milby via use-livecode <use-livecode at lists.runrev.com> wrote:
> If I'm understanding correctly, a capability to export a stack as an array
> (with the corresponding import) would get around the issue of the
> non-public properties though. The array would be the intermediate format
> that would be used by the engine to construct the stack in memory. LCS
> could be used to serialize into a suitable disk format. It would mean that
> the only way to get a full representation of the object would be to use the
> full import if there were properties like you described above (unless I'm
> missing something).
> I've actually been mulling something along these lines over for the past
> few weeks (but was thinking about a direct XML format). I briefly looked
> at the code to save a stack and noticed how it seems pretty straight
> forward. I'll take a look at the code for some of the objects this weekend
> and see what I think. Could be a good opportunity for the community to
> contribute a useful new feature.
More information about the Use-livecode