keeping default values through a logoff/shutdown

[catsh16]

So,

  I want my user to be able to change the default values, but not have to save the VI to keep the new values through a restart(ie exiting labview).

I currently have my VI set as password protected, which I believe eliminates the ability to change default values ('make current...')

Secondly, if I were to build my VI into an Application, how does this work? are the default values hard coded into the EXE, or are they called from an initilization file that can be updated? 

Any advice will be appreciated. 

ps. I've already glanced at this: http://zone.ni.com/devzone/cda/epd/p/id/1173  but am curious to hear a few more solutions 

Thanks,  Kevin

[NIquist]

As far as I know there is no way to store default values in an executable programatically (and I've tried).  Your best bet is to use the configuration VIs to generate an .ini file.  Save it as the last thing your program does, and load it as the first thing.  .ini files are text so you have the added advantage of being able to edit them offline.

[EdDickens]

Using the "Make Current Values Default" method does not work in an executable. As a matter of fact, it won't work from within LabVIEW if the VI you are trying set is running. This is because changing the default values requires the VI to recompiled and saved and you can't do that while it's running. And you really can't do that with an executable.

NIquist suggestion of using an .ini file the best way to go. Fairly easy to setup and maintain. There's some examples that ship with LabVIEW that show the basic setup needed. Open the Example Finder (Help menu>Find Examples) and on the Search tab, search for "Configuration". You'll see a couple examples named, Read Configuration Settings File and Write Configuration Settings File.

Ed

[catsh16]

Thanks guys,

  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.

[tst]

No, but OpenG has VIs which allow you to save and load all controls on a panel to an INI file. You can modify it to operate on specific controls by using their references and Value property.

[tbd]

Hi catsh16,

      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.

Cheers!

Message Edited by tbd on 07-29-2007 02:56 AM

[tst]

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.

[mikeporter]

You make a good point tst in that it points out a useful distinction between different kinds of defaults. (...blessed is the one who makes distinctions...)

There are some defaults where you are simply saving user preferences such as the order of columns in a table or the like. The proper operation of the software isn't really dependent upon these sorts of items. They are there as a convenience and so if they get messed up when the software structure changes it's probibly no big thing.

The other kind of defaults are things that the program needs for proper operation. For optimum security (no matter how you define the word) these shouldn't be saved in a file at all, but in a database. There is code posted elsewhere on the forum that makes utilizing a simple database almost as easy as writing to a text file.

Mike...

[tbd]

Hi tst,

---

@tst wrote:

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?

Cheers!

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!

[tst]

---

@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.

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.