How to save data from standalone?

Mark Smith mark at maseurope.net
Mon Feb 6 20:45:47 EST 2006


Also, we shouldn't ignore the idea of saving data in a stack, rather  
than a text document. Not a substack, but a separate, faceless stack,  
that simply has your data  in it's custom props, and mixing binary  
and text data is then possible, too. The size of an empty stack is  
about 4 Kb.

This makes it easy to keep whatever structure your data has natively  
in Rev, and makes it possible, if desired, to simply keep the data  
there, work with it, and save it whenever necessary. The stack can  
live wherever you choose, and you could easily store the user's name  
in it to identify it.

Stacks make excellent 'structured documents', and using them in Rev  
is obviously much easier and more efficient than working with XML.
Of course, you can't use this to exchange data with other apps, but  
in the worst case, any text data can still be recovered from it with  
a text editor.

Mark


On 6 Feb 2006, at 22:52, Jim Ault wrote:

> Marielle,
>
> What is 'massive' in your definition? 1 Mb, 2 Mb, 20 Mb?
> Using
>
> put cr&"<header>"&the seconds & "</header>"&cr & \
> theDataBlockToBeWritten & \
> after url ("file:/HD/User/Documents/thisAppFolder/dataForMe.txt")
>
> would separate the data by time written.
>
> Of course the URL could be an ftp server, if that would help.
>
> Is the data formatted or tagged?
> Is the data sentences/paragraphs, or short lines/phrases?
> Are you reading and writing to disk, or just writing?
>
>> 1. I thought I had read on this list that custom properties were
>> saved in standalone format
> The custom properties are saved in the RAM version of the  
> standalone, but
> are not written to disk.  Data could be stored in custom properties  
> and
> written/sent/memorized before quitting the app.  A single write  
> operation is
> actually quite fast.  Filtering is very fast.
>
> Hope this helps.
>
> Jim Ault
> Las Vegas
>
>
>
> On 2/6/06 1:54 PM, "Marielle Lange" <mlange at lexicall.org> wrote:
>
>>
>>>> 1. I thought I had read on this list that custom properties were
>>>> saved in standalone format that there was no need to create a  
>>>> splash
>>>> screen to handle this. What did I get wrong?
>>>
>>> If you need to save data changes then you need
>>> separate substacks; or create a splashscreen and use your  
>>> mainstack as
>>> a separate substack of it.
>>
>> But with multiple users, the data of one user gets overwritten by the
>> data of another one, no? Sarah's trick of storing the data within the
>> package content or some directory presents the same problem if I
>> understand correctly, doesn't it? Overwriting the data of one user
>> with the ones of another will be a real problem. I am not storing
>> preferences, I am storing actual data.
>>
>> I tried to talk some experienced (non revolution) programmer about
>> the file in the package solution. I was told to keep away from that.
>>
>> Using pathToUsersDocumentsFolder would therefore be a better
>> approach, but I don't really want to create a file within this folder
>> as the file is in a completely adhoc format that would puzzle anybody
>> who come across it.
>>
>> Eric's solution is the best one, but I have a long list of data to
>> save. I did consider it. The problem is that it's is not really
>> appropriate to store that amount of data in a preferences file. They
>> are not preferences, they are data.
>>
>> Has anybody ever tried the     User/Library/Application Support
>> way? Is there any problem associated with this solution? What's the
>> equivalent on a PC? I am not after a quick fix but after a "clean"
>> way to do this (compliant with developer's recommendations). I can
>> find this info for a mac, but I know little about PCs.
>>
>> Thanks for your help,
>> Marielle
>>
>
>
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your  
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution




More information about the use-livecode mailing list