Thanks for the thoughts on this conundrum.
Mark S' suggestion of restoring by saving the clipboardData["objects"]
by pasting is a good one and might be worth testing to see if this can
be done with LC Server, but since the clipboard version of a stack is
nearly twice as large as its native format I'm reluctant to spend much
time with that option in a setting already concerned with network latency.
Similarly, Alain's suggestion of serializing to a text format (I tend to
use arrays for object serialization now that we have arrayEncode(); I'm
lazy so I let the engine do the parsing <g>) would also be a good one in
some contexts but suffers from the same limitation as the binary
clipboard data in terms of size.
It's hard to beat the compact expression of stack data in the native
stack file format.
At the moment I'm resigned to allowing file I/O in the app,
rationalizing the use of a cache folder for other benefits beyond the
necessity of sending stack files back to the server.
For the future, I've submitted a feature request:
Request: copy <stack> to <variable>
<http://quality.runrev.com/show_bug.cgi?id=12639>
Also relevant for those of you who make client-server apps, an older
request that would be useful in some scenarios by limiting file I/O to
one specific folder, prohibiting all other reads/writes:
secureFolder
<http://quality.runrev.com/show_bug.cgi?id=867>
--
Richard Gaskin
Fourth World Systems
Software Design and Development for the Desktop, Mobile, and the Web
____________________________________________________________________
[email protected] http://www.FourthWorld.com
_______________________________________________
use-livecode mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
