Developing first on android

[Bob Sneidar]

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. 

Bob S


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