Very cool. I’ve used plists for years, but the compact elegance and auto-complete that your scheme offers is great. Nicely done.
Anytime 
Of course, you can adapt the class the way you want. Just make sure you meet the requirements of JSON.
The computed properties do help a lot with the autocomplete. Yeah, I’m rather lazy than tired 
Besides… I love the way Xojo allows us to wrap things in reusable classes. So, we only have to write those classes once and reuse them until the end of days.
Some functions (methods) in the support module I have actually written in a huge module, stuffed with convenience functions, I import as an external module. Very useful.
Thanks, I need to take a look into the JSON example to get things sorted that are too complex for just a text file to be saved.
In my JSON example, the real magic is in the support module.
You just add a computed variable (or duplicate one from the example). Just make sure you write to a method in the cfg-class-instance (yes, you can have multiple config files) with the name of that property.
I use “CurrentMethodName” to get the name of the calculated property. And since the CurrentMethodName returns (kind of a path) to the method, including the getter and setter, separated by a period, we need to extract only the part that is relevant.
In my case I often use a module to place the (computed) config variables. And that is “modConfig” (in my case)
So, an config integer for age is modConfig.age
And since I make use of a computed property, the full method name for the getter and setter are:
modConfig.age.get
and modConfig.age.set
And since I only need the actual property “age” name, I use the Xojo NthField function.
nm = CurrentMethodName.NthField(".", 2)This sets the variable nm to the 2nd field in the CurrentMethodName. Fields are in this case sperated by a period.
If you set the computed property scope to global, you can read and write to this property from anywhere in your app. I set it up that it saves the value everytime you change it.
But, you can easily change that initializing the cfg class. There is a property “AutoSaveOnChange” in there that will take care of that.
To really learn what is going on, I suggest examine the ConfigClass.
I have been using a dictionary to store whatever I need at close and restore at load.
What I appreciate most over a database is that I can add a new key at any time without any fuss.
Is json fast enough for multiple MBs of data? Especially, with High Sierra being so much slower with writing to the harddisk compared to Sierra.
From what I see, APFS was the offender in High Sierra writing. With HFS, it is comparable to previous versions.
That said, we never know which target machine users employ…
Problem is, at any rate, if the user has APFS, there is no workaround available, apparently.
JSON is a lightweight data-interchange format, I personally don’t trust that it could handle larger amounts of data in a reasonable manner. I also wouldn’t use it for storage, as that’s not what it was designed for.
As I mention to those looking to build a complex game in Xojo rather than a game engine, “use the right tool for the job.” I lean toward SQLite because it’s designed to store data. If late in a project I suddenly need to store a larger blob of data in my settings file, I’m not going to kick myself for selecting a lightweight format designed for network communications.
At this time my personal settings module isn’t well rounded enough to share publicly, so I must refrain from doing so. There are several existing solutions floating around the forum, however none satisfy my personal requirements.
It has been requested several times for a built in preferences system, I personally have points on <https://xojo.com/issue/18346> But y’all have been waiting for nearly 7 years, so I’m not holding my breath. Please add your voice (or points) if system native preferences are of interest to you!
I use the ancient “pList Class for Realbasic” from the apparently now-defunct MacCrafters for both prefs and my apps’ data files - it’s simple, readable, and intuitive, and the source is available. The Xojo XML classes weren’t available when I started using it and I’m not sure there’d be any advantage to switching. With pLists, storing large amounts of encrypted data is not an issue, although retrieving 30K of individual records for listbox population is slower than I’d like it to be.