Page 1 of 2
Standalone: Saving prefs
Posted: Mon May 08, 2023 4:00 am
by 5imon
Hi all,
I'm lost on where in the forum to find an answer for this question: If my standalone requires that a user modify settings in my app (for example they may change the bg color of the UI) then this needs to be saved externally to a custom plist/JSON/XML etc.
What is the current best practice for this? I was thinking I'd just write any customizations made by the user to a plist file. The issue is where this file goes, I see that the build process allows us to copy files with the build. So if I include a userprefs.plist then would I be able to still write to it? Or is it better to save those prefs to the user's Documents folder?
Any help to posts here that cover this is appreciated.
Re: Standalone: Saving prefs
Posted: Mon May 08, 2023 4:15 am
by dunbarx
Hi.
A common question.
The trick is to NOT have the "app" be the executable. No OS will save the executable. Once you grok that, just save away, as you might an ordinary stack in the IDE, and the "app" is, er, saved.
Now then, look up "splash" on this forum. Read a bit; there is a lot there.
If you still want a simple recipe, just come back.
Craig
Re: Standalone: Saving prefs
Posted: Mon May 08, 2023 9:48 am
by Klaus
Hi Simon,
on Windows use -> specialfolderpath("support")
on a Mac use -> specialfolderpath("preferences")
to store your prefs.
Best
Klaus
Re: Standalone: Saving prefs
Posted: Mon May 08, 2023 3:35 pm
by dunbarx
Simon.
You now have the other way to save information in a standalone app, an external file. Which to use is up to you. I always use the "Splash Stack" method.
Craig
Re: Standalone: Saving prefs
Posted: Mon May 08, 2023 4:33 pm
by 5imon
I'm absorbing the replies and continue to read what I can find — here's my current understanding:
[1] specialfolderpath()
I can store basic preferences such as window size, colors and fonts, preferred "save path" directory etc to an xml or json file. I don't really see any benefit to saving 4KB of string-based data to a new stack.
[2] create/clone stack "NewStack"
In the past I recall doing this from a standalone to create a new stack that the user can work in. I think the preferred method would be to clone a substack currently within my standalone (essentially a "template" stack) which has my custom layouts etc and let the user modify that clone and save it.
[3] Splash stack
I'm still unclear on the use case here. Conceptually I understand that you need the executable "Splash" to edit and work on data it can save to "the stack". However, as a practical matter, I can't seem to wrap my head on what's happening or what this solution looks like.
Can I assume that any solution using this method would be delivered as a runtime which has an accompanying stack sidekick?
For example, if the purpose of your standalone was to act as a plain text editor then is "the stack" your text editor which generates txt files or does the "Splash" contain the editor which saves data to "the stack"? Are you then constantly forking/cloning "the stack"?
Sorry for being dense, there are so many results when searching "Splash stack" that I have yet to find a practical example I can open to see how it's being applied in practice. On the surface it seems functionally similar to cloning a substack but "with extra steps" as the memes say.
Re: Standalone: Saving prefs
Posted: Mon May 08, 2023 5:40 pm
by jacque
For something like a prefs file I always just write a file to one of the folders Klaus suggested. The file can be in any format, it doesn't have to be a plist or JSON. If the data isn't critical, a plain text file is fine. If you need to store info securely you can encrypt it and then decrypt when you read it in. The file can be created on the fly as needed.
If you need to store images or LC controls then creating a prefs stack is a similar way to do the same thing.
Re: Standalone: Saving prefs
Posted: Tue Aug 15, 2023 9:24 pm
by bogs
I came here for a different purpose, however, the question posed was interesting to me, so I thought I would input my .02 (worth less due to inflation).
On the general question, Klaus (and Jacque's follow up) nail most situations, but Craig's answer deserves a little more explanation.
[3] Splash stack
I'm still unclear on the use case here. Conceptually I understand that you need the executable "Splash" to edit and work on data it can save to "the stack". However, as a practical matter, I can't seem to wrap my head on what's happening or what this solution looks like.
It can be like you see in the bold/italic/underlined above, however it usually is even simpler than that. You don't use the 'splash stack'
as the main program, but merely as a way to
launch the main program.
Since the main program is a non-compiled stack, as long as you have ...
Code: Select all
on closeStack -- automatically save changes
save this stack
pass closeStack
end closeStack
Then the actual application closes with all changes made being saved directly therein, so a preference file becomes redundant. Jacque mentions this obliquely in her reply about a pref's stack, however, you don't need the pref's stack at all in the above situation (other than to set the background color or whatever).
You will notice this behavior when editing stacks in the IDE, for instance, when you save a stack in work. The only difference here is that you are automating the stack saving in the stacks close request.
I hope that was of some help, if a bit late. If you would like to see a good demonstration of it, making one will be very easy.
Re: Standalone: Saving prefs
Posted: Tue Aug 15, 2023 9:26 pm
by richmond62
Personally I store prefs in my 'Home' folder as a simple comma delimited text file.
Re: Standalone: Saving prefs
Posted: Wed Aug 16, 2023 1:03 am
by stam
I must say that’s one of my big bears as a user. I detest it when apps clutter my home folder with random files, it’s just rude…. There are dedicated locations for preferences and really these should be used.
Re: Standalone: Saving prefs
Posted: Wed Aug 16, 2023 1:58 am
by richmond62
As Macintosh apps are disguised folders it is perfectly possible to save preferences inside them.
Re: Standalone: Saving prefs
Posted: Wed Aug 16, 2023 2:04 am
by jacque
I came here for a different purpose, however, the question posed was interesting to me, so I thought I would input my .02 (worth less due to inflation).
Well look who's back. Nice to see you, Bogs.
Re: Standalone: Saving prefs
Posted: Wed Aug 16, 2023 2:09 am
by stam
richmond62 wrote: ↑Wed Aug 16, 2023 1:58 am
As Macintosh apps are disguised folders it is perfecyly possible yo save preferences inside them.
You'd think so wouldn't you? But no........
Apps are immutable (even if it's a folder pretending to be an App bundle). You would break the codesigning if you edited the app bundle.
There is good reason you haven't seen
any Mac apps do this!
The correct place to put preferences on MacOS is in the Preferences folder of the user's library:
~/Library/Preferences
This is where
specialFolderPath("preferences") points to on Mac
As far as I can tell, there is no direct equivalent on Windows (I guess usually stored in the registry, if that's still a thing?). But I guess you could store a prefs file in the user's AppData folder - specialFolderPath("support") or Documents - specialFolderPath("documents")
Re: Standalone: Saving prefs
Posted: Wed Aug 16, 2023 11:22 am
by richmond62
Aha . . .
That is because I have only saved prefs files inwith Mac app 'folders' with standalones deployed on my own machines.
Re: Standalone: Saving prefs
Posted: Sat Aug 26, 2023 11:43 am
by Zax
I think the most reliable and easiest way is to store the preferences in an array, and use the arrayEncode() and arrayDecode() functions.
Here is a shortened example of what I always use:
Code: Select all
local gArrPrefs // preferences array
local gPrefsFileName // your preferences file name
on openStack
prefsDefaults // initialize default prefs
put "MyAppPrefs.bin" into gPrefsFileName // define your preferences file name
prefsFileRead // read previous prefs file (if exists)
end openStack
on closeStack
// eventually update prefs here...
prefsFileWrite
end closeStack
on prefsDefaults
put "YourData1" into gArrPrefs["data1"]
put "YourData2" into gArrPrefs["data2"]
put "YourSubData1" into gArrPrefs["data3"]["subData"]
// ...
end prefsDefaults
on prefsFileRead
put getPrefsFolder() & gPrefsFileName into prefsFile
if (there is a file prefsFile) then
put URL ("binfile:" & fichierPrefs) into encodedArr
put arrayDecode(encodedArr) into gArrPrefs // defaults prefs are overriden by existing prefs file
end if
end prefsFileRead
on prefsFileWrite
put getPrefsFolder() & gPrefsFileName into prefsFile
put arrayEncode(gArrPrefs, 7.0) into URL ("binfile:" & prefsFile)
if (the result <> "") then answer error "ERROR : Unable to save preferences file." with "Continue"
end prefsFileWrite
function getPrefsFolder
if the PlatForm = "MacOS" then
return specialFolderPath("preferences") & slash
else return specialFolderPath("documents") & slash
end getPrefsFolder
Re: Standalone: Saving prefs
Posted: Sat Aug 26, 2023 12:39 pm
by richmond62
Why not store preferences as a comma-delimited text file?
Here's some code I nicked from some of my own work [Devawriter Pro] just for saving a textField . . . which can, quite obviously be used to export the contents on a tableField:
Code: Select all
ask file "Choose where you wish to export your text"
if the result = "cancel"
then exit mouseUp
else
put the RTFtext of fld "fRESULT" into url("file:" & it & ".rtf")
get the longFilePath of it
set the itemDelimiter to slash
set the defaultFolder to item 1 to -2 of the longFilePath of it
end if
As long as you are confident about the file structure of your clients' computers [risky, very risky] you can set the
automatically, rather than let a client choose their own location; thereby making it easy for your standalone to 'know' where to look for a prefs file.