I really like this thread, as this is an area I am always trying to improve.
I used to write config files like this (bar the input into class just output a cluster, esp for <2009 RT apps):
The only thing I can add is that I found it easier using an enum as the key due to typos, esp when the number of keys get large, but that was just personal preference.
Where variants can be used, I prefer to leverage existing APIs (such as OpenG) as it just so much less work to read and write to disk and extends the LabVIEW Config API by supporting other datatypes (e.g. arrays).
Here is how I do configs with LVOOP.
Mentioned in other threads I like to write the Object's private data to disk from within the Object.
The data that is required to be persisted is stored in a non-typedef cluster.
I usually end up having reusable Objects, application Objects (including general Config Objects) that I want to flatten to disk.
These can be basic Objects, extended Objects, MFVIs/modules, arrays of Objects and Objects composed of other Objects - I am able to do this albeit there is a little more work for the last two.
Typically I like to use a single ini file (as I like the format).
I'll use a simple application as an example
Here is the startup code for the application, it is quite simple and contains reuse modules (the purple banner object extends the blue banner object):
Inside the second VI from the left (curves settings constructor) the structure of the file is setup (header, sections):
When the Read VI (reuse) is called in the startup (third VI from the left) it performs checks, reads the header (meta data) and then the section data
The section data is an override VI which extends the base case and is custom for every application. It calls the Object's read to disk method
The reading is delegated to a File Interface (reuse) Object (not shown) which has a variant interface - it may not be the best interface but I found this was the easiest way for reuse.
In the base implementation it uses OpenG ini format (abstracted under a few layers) as this is my preferred approach plus you can't really have abstracted Classes in LabVIEW etc...
In the end this is what the file looks like, and it is minimal effort to create using the reuse modules:
Additionally I can support versioning if required for that application in the future.