keeping default values through a logoff/shutdown

[EdDickens]

One reason I stick with ini files is it's usually a customer requirement that they be able to edit the file externally from the application. I always warn them of the consequences of editing the file and messing something up, but it seems to be something they always want. I offer to build a little app that can edit the file separately from the main app, but it almost always gets opened in Notepad at some point. So in the main app where I read the file, I set it up so it not only uses a default value if a key is missing, but also checks the values to see if they are in a certain range that makes sense for that key. Then a dialog pops up to notify the uses that something isn't right and they should check it before continuing.

Ed

[Ben]

Yair,

I have not looked at the OpenG save restore recently, but when last I looked, the data was saved as a variant and therefor was a challenge to edit via notepad.

Is that still the case?

I'm concidering doing a Nugget on a universal save-restore that uses plain text in "ini" format but if OpenG alredy does this, then there is no need.

Just looking for a "hole to fill",

Ben

[tst]

The parser converts each element in the variant into the appropriate type and then uses the native config file VIs. If it encounters an array it formats it using a format which works but which is not the easiest to edit by hand and if it encounters a cluster it deals with it recursively. For unrecognized data types, it flattens them to a string.

If you're allowed, you can see an example here which has the OpenG VIs as well. If not, this is what it looks like, including the resulting file:

P.S. This is how you load (and save) previous values using the VIs I posted earlier. It couldn't be much simpler.

[tbd]

Hi All,

I'm not arguing against INI files! They're invaluable!  I've "rolled my own" VIs to support trailing comments and sub-blocks (delimited by curly-braces), however...

My sense was - reading the original post - Kevin wants to save GUI-settings between runs.  This can be accomplished so simply and reliably without the complexity inherent in using/maintaining the INI format, it seems a shame to push him down the INI road - though he'll certainly learn more while implementing an INI solution.

Tst, the last time I used OpenGs cluster-to-INI converter (about 7 months ago), this cluster caused it to blow-up:

The OpenG converter relies on parsing the undocumented "type-string" the format of which NI is free to change in future versions of LabVIEW (I don't think this will happen, but I'm sure you'd point this out if it was MY code parsing the type-string).  Since 7.1. Cluster to XML has been available and IMHO should be used to "unflatten" the cluster to XML - a well known and documented format.  An XML to INI converter would create the INI.  Currently, OpenGs Cluster-to-INI converter is a one-way conversion - the resulting INI can't reliably be converted back to a Cluster.  This is because structural-information is lost during the conversion to INI!

Cheers!

Message Edited by tbd on 07-30-2007 10:42 PM

[tbd]

Hi tst,

      Look, if someone needs to store program settings in an easy-to-edit format, INI of course!  But if Kevin just needs to preserve a few values that he can afford to replace occasionally - when he edits the type-def - then the flatten-to-string is much simpler.

---

@tst wrote:

---

@tbd wrote:

How can the OpenG tools "survive" a missing/mis-named INI parameter, if not by applying some default? 

---

Yes, but the key is that the default is applied per key and not for the entire file, so if you add a new field, your old configuration is not lost.

---

Perhaps what's "key", here, is that you must "add a new field" or the INI is broken, that is, the INI must be maintained; it also invites post-deployment changes, and it adds complexity - not just the complexity exposed to the programmer by the tool-set, but the addition of non-trivial VIs which manipulate undocumented data "type-string"s (OpenG) - to me, this is a noteworthy liability.

---

@tst wrote:

The main difference is that your VI does both reading and writing and the OpenG VIs do not create a key which is not found, but you can easily modify them to do that. In fact, I have done such modifications for simpler INI VIs.

---

With respect to ease of implementation, and maintenance, I think the "main difference" is that your OpenG solution requires inclusion of much non-trivial code and a toolset that isn't distributed with LabVIEW.  This isn't to say Open Source is bad, it's just an observation that your solution includes this dependency.  Anybody who's opened a VI that was built with a toolset not installed on their computer know what I mean.

---

tst wrote:

P.S. The flatten method may be easy to use for GUI controls, but I think the VIs I posted in reply 7 are even easier.

---

Yes, tst, but for you, Everything is easy.

Cheers.

[tst]

---

 Anybody who's opened a VI that was built with a toolset not installed on their computer know what I mean.

---

That is a legitimate claim, but it only applies when you're talking about distributing code, not for executables. Over here, placing OpenG under the SCC tool's control works for synchronizing. A better argument might be that some people avoid using open source code completely for legal reasons (see Ben, for instance).

---

you must "add a new field" or the INI is broken, that is, the INI must be maintained; it also invites post-deployment changes, and it adds complexity - not just the complexity exposed to the programmer by the tool-set, but the addition of non-trivial VIs which manipulate undocumented data "type-string"s (OpenG) - to me, this is a noteworthy liability.

---

That is simply not true. The read VI does not add keys if they are not found, but the write VI definitely does. You don't have to maintain anything other than the typedef. That's part of what makes it so easy to use.

The complexity of the toolset is exposed to the programmer only if the programmer decides to look inside. If the programmer simply uses the interface, it works exactly like in your code.

The type strings are not undocumented. They are documented in the LabVIEW Data Storage white paper which (at least in my 7.0) comes with LabVIEW. It is even pointed to both from the Variant to Flattened String help and from the Flatten to String help. The main problem is that the format was changed with 8.x (where it might be undocumented) and that presumably some of the code needs to be rewritten to work with the new format, but I assume the old format is still supported and will be so for quite some time, just like the type cast still has the 4.x option and like Unflatten from String has the 7.x option. In any case, that's an implementation detail. The conversion could be written to be done automatically. It might be complicated, but I'm sure it can be done.

I'm assuming that what happened with your example was that you were working with the 8.x format, which is not supported, but I haven't looked into that. I (as well as many others) use it regularly for much larger clusters and I can definitely say it works.

As for your "invites editing" comment, I can't argue about that, but that can also be worked around. The main point was that it survives changes. In my example, if I were to add another control to the array of references, the existing controls would still load their previous values. That might be a small detail, but it makes the program easier for the user.

[tbd]

Hi tst,

      I stressed all day expecting to be called-out on the claim that OpenG's Cluster to INI converter is necessarily "one way".  I'm wrong    By using the original type-def, OpenG could (and, for all I remember, does) correctly read-back INI data - regardless of whether differently structured clusters produced the same INI.

---

@tst wrote:

---

you must "add a new field" or the INI is broken, that is, the INI must be maintained; it also invites post-deployment changes, and it adds complexity - not just the complexity exposed to the programmer by the tool-set, but the addition of non-trivial VIs which manipulate undocumented data "type-string"s (OpenG) - to me, this is a noteworthy liability.

---

That is simply not true. The read VI does not add keys if they are not found, but the write VI definitely does. You don't have to maintain anything other than the typedef. That's part of what makes it so easy to use.

---

I was referring to a "traditional" INI solution, but this OpenG utility does make it simpler - OK, I'll buy that.

---

The complexity of the toolset is exposed to the programmer only if the programmer decides to look inside. If the programmer simply uses the interface, it works exactly like in your code.

---

The toolset does add complexity, and that's a liability - even if the programmer doesn't open-the-hood to see what's inside.  Every extra file-system object - even every extra wire - means additional complexity => liability.

---

I'm assuming that what happened with your example was that you were working with the 8.x format, which is not supported, but I haven't looked into that. I (as well as many others) use it regularly for much larger clusters and I can definitely say it works.

---

My recollection (for what it's worth) is that the bug occurred because the child-cluster had the same name as the parent-cluster (as shown).  I think this code is still installed on another computer here - I'll look for it tomorrow.

>The main point was that it survives changes.

Yes, I've appreciated this from the beginning.  To me,this is a cost/risk question - what's the likely-hood of a type-def change, and whats the cost of loosing the last "defaults".  If cost X risk is low, then accept the (occasional) losses - the expense (in code) is, say, 6-primitives.  If cost X risk is "high", then go the more expensive (code-wise) INI route.

Cheers!

[tst]

---

@tbd wrote:

I stressed all day expecting to be called-out on the claim that OpenG's Cluster to INI converter is necessarily "one way".  I'm wrong    By using the original type-def, OpenG could (and, for all I remember, does) correctly read-back INI data - regardless of whether differently structured clusters produced the same INI.

---

I simply thought that you had a specific problem when back converting. I didn't realize you were talking about something more general. Anyway, the answer is yes - the OpenG read VI uses the structure of the cluster you give it (names and types) to build a variant cluster which can then be converted to a cluster and this method survives changes because even if there are missing\extra elements, it simply ignores them or uses the default value.

---

The toolset does add complexity, and that's a liability - even if the programmer doesn't open-the-hood to see what's inside.  Every extra file-system object - even every extra wire - means additional complexity => liability.

---

That sounds right.

---

My recollection (for what it's worth) is that the bug occurred because the child-cluster had the same name as the parent-cluster (as shown).  I think this code is still installed on another computer here - I'll look for it tomorrow.

---

I don't think that should happen, since the code uses a period delimited format to save the data, but I suppose it's possible. If this is reproducible, it should be reported to OpenG.

---

If cost X risk is "high", then go the more expensive (code-wise) INI route.

---

I usually prefer the "try to stay consistent and have contingencies if possible" route, but I understand your view. For what it's worth, the code is also expensive in execution time.

[tst]

---

@tst wrote:

---

The toolset does add complexity, and that's a liability - even if the programmer doesn't open-the-hood to see what's inside.  Every extra file-system object - even every extra wire - means additional complexity => liability.

---

That sounds right.

---

Now I realized what was bugging me about this. It does sound right, but it isn't exactly right. It is true that extra code adds extra complexity, but a reusable tool with an easy to use interface and good edit\debug options (the resulting INI file) saves complexity over multiple projects.

BTW, a relatively simple way to avoid having users play with your configuration files is to give them another extension. Most users would not try to open files which have, let's say, a PAK extension in Notepad.

[tbd]

---

@tst wrote:

---

The toolset does add complexity, and that's a liability - even if the programmer doesn't open-the-hood to see what's inside.  Every extra file-system object - even every extra wire - means additional complexity => liability.

---

That sounds right.

---

Now I realized what was bugging me about this. It does sound right, but it isn't exactly right. It is true that extra code adds extra complexity, but a reusable tool with an easy to use interface and good edit\debug options (the resulting INI file) saves complexity over multiple projects.

---

; code-factoring on a multi-project scale?  A bullet-proof INI solution does sound attractive, though the OpenG type-string parsing doesn't thrill me (seems it could break all by itself, after a new version of LabVIEW), neither does being dependent on OpenG for a "fix".

Here it would be holding-back not to admit already tolerating type-string parsing (of my own).  Though this code functioned across 6.1/7.1, your warning about 8.x is appreciated - as well as the comment about documentation being available.

Cheers!