Standalone not saving changes

[CAsba]

Hi,
I just discovered that my provisional standalone "checking" version does not save user-made changes. Reading up on the app building forum, I get it that there is an external db method to get around this. Before I knew all this I was thinking of using sqlite instead of a datagrid (hoping that might have been the easier course of action). My question is, if I use sqlite, will it require another EXTERNAL db to save the user-made changes ?

[Klaus]

Hi CAsba,

yes, standalones cannot save themselves, on no platform.
And we are not allowed to write (= save) data in the Application folder, on no platform.

You will need to write the data into a writable folder and on mobile the only folder we have
write permissions is -> specialfolderpath("documents")

How much data do you need to save? Maybe a simple text file will suffice?

My question is, if I use sqlite, will it require another EXTERNAL db to save the user-made changes ?

Not sure what you mean, but of course the db file will also need to be saved in a writable folder like above.


Best

Klaus

[CAsba]

Hi Klaus,
Many thanks for your prompt reply.
My project is a business accounts package, so there will be lots and lots of data to be saved.
Well, if I understand you correctly, if I used the sqlite db as a method of saving data within LC, I would need a seperate db externally. I guess this would mean that I would have to distribute the package as an LC standalone PLUS an external db. That would not be feasable I think. What say ?

[richmond62]

Possible you could save your data as a delimited Text file.

[Klaus]

hi CAsba,

Hi Klaus,
Many thanks for your prompt reply.
My project is a business accounts package, so there will be lots and lots of data to be saved.
Well, if I understand you correctly, if I used the sqlite db as a method of saving data within LC, I would need a seperate db externally. I guess this would mean that I would have to distribute the package as an LC standalone PLUS an external db. That would not be feasable I think. What say ?

EVERYTHING is possible with LC! (OK, almost)

You can set up your database with all neccessary tables and fields etc., add it to your runtime via the "Copy files" tab in
the "Standalone Application Settings" and then later just copy that file to the users DOCS folder, like I showed here:
https://forums.livecode.com/viewtopic.p ... le#p183562

This way you can even have a "savable" stack in our runtime, just replace the db file with your stack-2-b-saved.

Best

Klaus

[CAsba]

My question was would I have to distribute the app with an external database ? If this is the case I wouild have to find another solution I think.
I just read up on the splash back launcher method. Would this be suitable with LC holdong lots of data, in your opinion ?

[Klaus]

My question was would I have to distribute the app with an external database ? If this is the case I wouild have to find another solution I think.
I just read up on the splash back launcher method. Would this be suitable with LC holdong lots of data, in your opinion ?

The "external database" is just a little file in the users DOCs folder and LC has the means to manage the database
(read, write, update search etc.) so I don't understand your problem?

And a SQLite db is better suited for "big" data than LC!

[dunbarx]

CAsba.

Unless you have a very large amount of data, and frankly, I have never been sure why size matters, there is another way to save data in a standalone without going outside of LC.

It is called the "Splash" stack method. You create a stack, which may not do anything at all, called a "splash" stack. That stack is the actual executable, and no changes in it can be saved. But one or more additional stack files can be included with that stack, and their changes can ALL be saved.

I do this all the time. My splash stack typically does nothing but open another stack, and that is where all my actual saved work is done. The "Standalone Applications Settings..." menu in the "File" menu allow you to include other stack files onto your splash stack file.

Try it. Make a stack and save it. Make another stack and save it as well. Add any sort of simple functionality that you want to save to the second stack. When you make a standalone from your first stack, "include" the second one in the settings pane. A little practice, and it becomes second nature.

Craig

[Klaus]

Yes, but as I wrote:

And we are not allowed to write (= save) data in the Application folder, on no platform.

So ERVERYTHING that needs to be saved MUST be copied to the users DOCs folder and opened from there
as shown in the script I linked to. At least for MOBILE.

On the desktop there are some more possibilities to put a "savable" stack.

[CAsba]

Many thanks. Things to try..

[stam]

As others have mentioned, since you sound like you need local file storage rather than an online db solution, it’s quite simple:

Store the data in a writeable location on the filesystem: my preferred location would be

Code: Select all

specialFolderPath(“support”) & “/<your_app_name>/

but other locations such as documents also work (lookup the specialFolderPath dictionary entry).

As to what format the file is in, that depends on your data. If fields are likely to contain delimiters such as carriage-return, I’d probably steer clear of text files - but if not a simple TSV or CSV (sorry Richard!) may suffice. You could just load/save the dgText of a data grid for example.

You can also just use normal livecode files, loading them with a splash’s stack as mentioned.

It’s also possible to write out arrays as binary files.

If you have a lot of data that you need to query, it may be preferable to use SQLite, which is both very fast and compact and means you can view/edit/query the data in non-LC apps as well.

With your use case in mind I’d probably go with the latter. SQLite is compact, fast, portable to other environments as is, and an industry standard.

HTH
Stam

[CAsba]

Hi,
I'm still having problems, even though I have made successful working standalones, I now find that the standalone looks and acts like a standalone but does not save changes.

I have used the following code on the launching stack (which is 'Run CAsba'):

"on openStack
set the itemDel to "/"
if the environment is "standalone application" then
if the platform is "MacOS" then
set the folder to item 1 to -5 of the filename of this stack
else
set the folder to item 1 to -2 of the filename of this stack
end if
else
set the folder to item 1 to -2 of the filename of this stack
end if

open stack "Casba accounts.livecode"
close stack "Run CAsba"
end openStack"

I also did a save with Ctrl-S on the code.
Any ideas how I could add anything to make it save changes ?

[Klaus]

Sigh...

Code: Select all

on openStack
   set the itemDel to "/" 
   if the environment is "standalone application" then
      if the platform is "MacOS" then
         set the folder to item 1 to -5 of the filename of this stack
      else
         set the folder to item 1 to -2 of the filename of this stack
      end if
   else
      set the folder to item 1 to -2 of the filename of this stack
   end if
   open stack "Casba accounts.livecode"
   close stack "Run CAsba"
end openStack

Mabe you mean -> specialfolderpath("resources")
This specialfolderpath points to the folder where you will find all files and folder that you have added
to your standalone via the "Copy filkes..." tab in the Standalone Application settings
And it does it on EVERY PLATFORM, wherever this folder may be, so please use it!

In my first posting here I wrote:

yes, standalones cannot save themselves, on no platform.
And we are not allowed to write (= save) data in the Application folder, on no platform.

You will need to write the data into a writable folder and on mobile the only folder we have
write permissions is -> specialfolderpath("documents")

Re-read the second sentence!
This folder - specialfolderpath("resources") - IS IN FACT inside of your application bundle on a Mac and on Mobile,
not sure about Windows. So SAVING silenty fails!

Best

Klaus

[Klaus]

Addition:

Code: Select all

...
close stack "Run CAsba"
...

If that stack is your runtime, this line has no effect, since the runtime (and the stack you created it from)
will always stay in memory.

[stam]

Hi CAsba
please use the 'code display' button for your liveCodeScript - just select the code you copy/pasted and click this button:

and then everyone can read your code easier. It's a common courtesy on the forum...

Hi,
I'm still having problems, even though I have made successful working standalones, I now find that the standalone looks and acts like a standalone but does not save changes.

erm yes, you can't modify the standalone once it's built. You can have the standalone launch other stacks which you can modify/save, which is common practice if saving data is needed.

But be aware than not uncommonly the /Applications folder is read-only, so if your app resides there, it won't save stuff. That's why the stacks may reside in other folders, such as specialFolderPath("support") and specialFolderPath("documents"), which are writeable locations.

"on openStack
set the itemDel to "/"
if the environment is "standalone application" then
if the platform is "MacOS" then
set the folder to item 1 to -5 of the filename of this stack
else
set the folder to item 1 to -2 of the filename of this stack
end if
else
set the folder to item 1 to -2 of the filename of this stack
end if

open stack "Casba accounts.livecode"
close stack "Run CAsba"
end openStack"

Not sure I understand this, but perhaps you mean you want to use the folder that contains your standalone? not advisable, as above. Also, you may want to ensure the data is kept safe for example when updating the app, so the data is not deleted when the app is deleted - again consider using an alternative folder.

If you look at the dictionary entry for specialFolderPath, there is a list of these:

Windows
"home": The current user's profile folder
"desktop": The current user's desktop folder
"documents": The current user's "My Documents" folder
"support": The current user's application-specific data ("AppData") folder
"system": The Windows System folder
"start": The folder that contains Start Menu items
"fonts": The folder that contains fonts
"temporary": The folder where temporary files can be placed
"engine": The folder containing the LiveCode engine and the executable files copied in the standalone application
"resources": In development mode, the current stack's folder. In a standalone, the resources folder where files or folders specified in the Standalone Builder are located. Note: A valid resources path is only returned after a stack has been saved.

Mac OS
"home": The current user's home folder
"desktop": The current user's desktop folder
"preferences": The current user's preferences folder
"documents": The current user's documents folder
"support": The current user's application-specific data folder
"system": The System Folder (usually /System)
"fonts": The folder that contains fonts
"temporary": The folder where temporary files can be placed
"engine": The folder containing the LiveCode engine and the executable files copied in the standalone application
"resources": In development mode, the current stack's folder. In a standalone, the resources folder where files or folders specified in the Standalone Builder are located. Note: a valid resources path is only returned after a stack has been saved.

Usually best to use these as a staring point for deriving folder paths... that does mean that your splash stack will need to check for existence of the files in these locations and if they don't exist then copy them there from the specialFolderPath("resources") folder - which in the standalone is where all the included stacks are put.

S.