Save Last Value?

[immercd1]

We all know the limitation that the "Data Operations"-->"Make Current Value Default" operation when right clicking controls is limited to edit-time only. 

I often find myself writing code to save the last value that a user has entered in some sort of ini file (ini, xml, .dat, etc...) so that the next time the code starts up, the last values are reloaded to those controls.  I have written some generic code that handles this functionality by wiring in control references.  It then monitors those controls for changes and it saves the values to "VI Name"+"_Last.ini".  Upon startup it loads the last values from that .ini file.  The two attached VI's show this functionality.  One VI is a Daemon that spawns the main process asynchronously so that the coder doesn't have to handle it themselves.

It would be nice if this could be handled intrinsically in LabVIEW.  What I'm envisioning is a checkbox for every control that, if checked, would function similarly to how the above code works: it would save the control value in a .ini file associated with the owning VI.  Since this is built-in it should also have accompanying properties for the control property node so that it could be accessed pragmatically and fired programmatically with the "Value Signaling" property. That would be awesome!

[PaulG.]

Clever. I like it. I've done what you're doing on occasion and would fing this feature built-in very useful.

[A-T-R]

hm...and you would like it to have for every single vi, right? That means that from now on, you would have not only the VI but also a corresponding ini file. For every single vi. otherwise, those value information has to be saved as some sort of meta data directly within the vi. would that be possible?

regards

[AristosQueue (NI)]

immercd1: there's a bug in your current implementation. You try to calcualte a path outside of the EXE in the run-time engine case, but the path you calculate won't always get you out of the EXE. The directory structure inside an EXE matches the directory structure on disk at build time (unless you use the "8.0 compatibility mode" during build which has other negative side effects so I don't recommend it). Instead of trying to calculate a path, use this function:

In the dev environment, this returns a path to the directory containing the VI that calls it. In the EXE\DLL, it returns a path to the directory next to the EXE or DLL. For many things, I can use this primitive for both the dev and runtime environments and get away from having a conditional compile structure. Oh... and that conditional compile structure won't work for building into a PPL which always compiles for not the runtime engine even though they can be loaded into both (unlike a DLL or EXE). Using this VI will help your code, however, even doing that may not be enough as I explain below...

A-T-R asks:

> those value information has to be saved as some sort of

> meta data directly within the vi. would that be possible?

No because we do not ever alter the VIs in the run time engine -- those are built into EXEs, DLLs and PPLs. Those VIs are unalterable after distribution. Thus we avoid creating LabVIEW features that rely upon altering the save images of the VIs themselves. In this case, the feature would have to know how to adjust its save path so that it saves a config file next to the VI in the dev environment and next to the EXE in a run-time environment -- except that writing to the EXE directory is often impossible because of installer lock-outs and the data has to be written to a writable location, i.e., the LabVIEW Data Directory with a subdirectory created for that particular EXE.

The config files themselves would need to be named using a mangled form of the qualified name of the VI not just the file name since multiple VIs would all be the same file name in any application using library namespaces -- standard practice for any reasonable size development these days. And if you are using LV classes, the VI that needs to save config information has a high probability of being the same file name VI in multiple classes, pretty much guaranteeing a collision if you only use file names.

As an alternative to mangling the qualified names, you could replicate the directory structure found inside the EXE/DLL/PPL into the subdirectory in the LabVIEW Data Directory. Take the Application Directory path mentioned above and the VI's path and then find the common path between them. Then create those subdirectories in the subdirectory in the LabVIEW Data Directory.

(You don't have to use the LV Data Dir for all of this, but there is a convenient primitive for that in the palettes and LV does all it can to guarantee that directory is writeable at runtime on all of our platforms, so it is what I recommend for this sort of thing. But some users don't like that their EXE has the word "LabVIEW" anywhere in its operation, so you can almost always take our directory and drop the last segment and create your own directory entirely isolated.)

[crossrulz]

AristosQueue wrote: In the dev environment, this returns a path to the directory containing the VI that calls it.

---

Actually, it returns the path to the folder containing the Project.

Ok, just reread the help file.  The path of the folder of the top level VI is given if not using a project.

[natasftw]

Why not just use the Invoke Node?  I'd much rather use the Invoke node than have an ini file for EVERY VI I write, whether I need it or not.

The right-click ability only exists during edit time.  If you're looking to right-click, you can easily add something like a button that triggers an event to run the Invoke Node with "set current values to default."  This isn't something you should need the environment to add for you to accomplish.  You're also able to create events that handle right-clicking and create something that looks like what you want it to look like exactly.  You could port that code into applications where you're worried about this functionality.

[crossrulz]

As was already said, you cannot change executables.  Those VIs are not editable.  The Set Current Values To Default would require a change to the VIs in the EXE.

And how do you think other programs keep their latest values?  They use configuration files (of some sort).  Why should LabVIEW be any different?  And there are a few libraries out there that save and restore all control values to a VI front panel.  Some are as simple as a single VI call.

[AristosQueue (NI)]

> Why should LabVIEW be any different?

More importantly... why should the applications that users write *using* LabVIEW be any different? We frequently end up different from various standards for various reasons, but we try to avoid such things without a good reason. In this particular case, there's an excellent reason: multiple users on one machine have different settings -- editing the EXE would change for everyone.