Saving application state for later resume

[Sam_Sharp]

The built-in LabVIEW XML files are horrible for configuration files, and here's why I think that:

- If you change your configuration type definition and then try to load an existing configuration file, you will get an error and you will get none of the data out of the file (except maybe the default values?)

- The XML it produces is horribly unreadable, not very efficient (too much padding!) and flat (having an array of items or individual sections you can read/write is a pain because of the LV XML schema).

I use the OpenG variant configuration file because it's super simple and I can change the configuration cluster as often (mutation) as I want and it will load the values from the file if they exist, using default values for new elements and it's also human-readable for easy editing.

Here's a 'generic' version of my load VI:

The type definition defines the configuration items and in the load VI I can specify the default values in case they don't exist (or the file doesn't exist). It will also write them back to the file (creating it, if it doesn't exist).

[Kyle97330]

---

@Sam_Sharp wrote:

The built-in LabVIEW XML files are horrible for configuration files, and here's why I think that:

- If you change your configuration type definition and then try to load an existing configuration file, you will get an error and you will get none of the data out of the file (except maybe the default values?)

- The XML it produces is horribly unreadable, not very efficient (too much padding!) and flat (having an array of items or individual sections you can read/write is a pain because of the LV XML schema).

---

I can't argue with the second point, but in regards to the first I would like to point out that if you save a LabVIEW class to XML instead of just a type-defined cluster, it can always read an old file without throwing an error and you will get all of the data out, though of course new fields will have their default values as the old version didn't have them to save in the first place.  This is done because the .lvclass file keeps internal records of all previous versions, and the XML encoding for a LabVIEW class includes the version number.

[Sam_Sharp]

Agree with you Kyle - it's OK for saving LV classes because the classes have a whole heap of mutation data within them - but even with that I think there are some caveats from what I recall from the OO course I did a few years ago.

(e.g., here's one - if you try to unflatten data from a future version of a LabVIEW class, LabVIEW returns an error. For example, this error might occur if you have data with a version number of 1.0.0.3 but the LabVIEW class in memory is version 1.0.0.2. So if you update an application to use a newer version of the class, you won't be able to open it with an older version of the application)

Therefore you can only go forwards - you can't go backwards. If you're using the configuration file options, you can delete individual keys, open it with an older/newer version of the application - I consider it to be far more robust!