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@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. _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
