This is what I thought the answer was, I was just thinking that perhaps NI had designed something really simple that I wasn't aware of.
If you only want to retain [not edit] values between runs, you might consider bundling the target values in a (typedef'd) cluster, then writing the flattened-cluster to a binary file (see pic). When app starts, it reads the file and unflattens "LastRun" values. Nothing wrong with INI files - I just like keeping the code as simple as possible. Do you want to be able to see/edit the values between runs?
Utility.File.WriteRead.vi just replaces or appends any string to a file, or reads a file's contents.
Message Edited by tbd on 07-29-2007 02:56 AM
The main problem with a flattened string (particularly when using a typedef, which encourages changes) is that when you change it you have to convert the current file to the new format. The OpenG VIs are as simple as that externally (although relatively complicated and slow internally), but have the advantage of producing INI files and surviving changes.
Here is the method I refered to earlier (7.0). In this case, it uses OpenG code inside, but the same thing could be achieved by flattening the value to a string.
The main problem with this is the VIs are confusing because they both get an array of control references. Perhaps changing them to be a single VI and adding a required Read\Write input would make it more clear what is being performed.
The main problem with a flattened string (particularly when using a typedef, which encourages changes) is that when you change it you have to convert the current file to the new format.
INI files also invite changes that can break the program (even post-deployment.) How can the OpenG tools "survive" a missing/mis-named INI parameter, if not by applying some default? Whether during development or after deployment, if the LastRun typedef changes, then yes, GUI-User defaults are reentered once. If this is burdensome, use a default-cluster when unflatten-from-string fails.
If there happen to be any really critical "defaults", my preference is to embeded fail-safe values as a program-constant (cluster-constant) to be used if unflatten-from-string (or INI-file reader) errors-out.
Mike, I liked your observation that we should focus on the nature of the data, but to me the distinction (between whether to use flatten-to-string or INI) isn't made on the basis of whether read-values are consistent with proper program operation - either method can handle that. I make the distinction based on whether the user needs to read/edit the values. If user doesn't need to edit the values, making them editable seems a liability and flatten-to-string method as simpler and safer. Sure, an INI file could be made read-only, but that seems illogical here.
I know from experience that the flatten-to-string method (for GUI settings) is simple, reliable, and easily adapts from one project to the next - are you sure you won't try it?
P.S. Kevin, if you go the INI route, beware that the NI's Read Key.vi (see File\Configuration File VIs) may not return an error even if requested-key is completely missing from INI file!
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.
This is an advantage which has nothing to do with whether the user will need to edit the configuration or not. Since using the OpenG VIs is as easy as using the VIs in your image (in fact, they work in exactly the same way, only with a variant instead of a flattened string) I don't see any simplicity advantage to the string method. 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.
the NI's Read Key.vi (see File\Configuration File VIs) may not return an error even if requested-key is completely missing from INI file!
It's not "may not". It simply won't. Instead, it has a boolean output to tell you if the key was found or not.
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.