LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Enumerating controls and saving to a config file

Hiya

What I want to do is cycle through the controls on a form, saving their values to a config file which can be reloaded when the vi is next opened.

The Visual Basic equivalent would look like:

For Each Cntrl in MyForm
print #1, cntrl.text
Next

I've worked out how to get all the values out of the controls, but there doesn't seem to be a way of uniquely identifying the control (as control labels do not have to be unique). Is there any way of doing this? The "owner" property looked promising but I think it's a blind alley.

Any suggestions anyone? I've attached an example vi.

Many thanks

Joolz
0 Kudos
Message 1 of 15
(3,273 Views)
An easy solution is to put all controls in a cluster and wire that to your "read/write user settings.vi".
This is an ancient LV-technique that still works (sorry still got LV5.1 so could not read your code).
Is this what you mean?
0 Kudos
Message 2 of 15
(3,273 Views)
It sounds like it.
Do I have to write my own "read/write user settings.vi" or is there an example somewhere?

Cheers

Joolz
0 Kudos
Message 3 of 15
(3,273 Views)
Is there a reason why the controls cannot have unique names? If there's a reason that they all must appear the same, can you name them uniquely, hide the labels as show the like named captions?
0 Kudos
Message 4 of 15
(3,273 Views)
I actually try and keep all my control names unique, and my alternative plan is to search for duplicate control names before saving the file.

I just thought that in the interests of "programming political correctness" I should try and find a better way of doing it.

Joolz
0 Kudos
Message 5 of 15
(3,273 Views)
If you want to save the values as the defaults I think you could use the VIServer to set them as the defaults and then save the VI via the server. There have been posting here on that. I believe that the VI can't be compiled but you can compile a front end loader program that launches your vi in its native code format with the VIServer. This should be able to be accomplished transparently.

I use a loader to launch my uncompiled apps and use the VIServer to allow users to edit global variables and then save the defaults as sort of 'visual' .ini files. LV handles all the file i/o and the apps read the globals in when they run. Unfortunately I can't use some of the properties available for regular VI's like hiding the menu bar, etc. to get the l
ook I want. So recently I've been writing the apps with all my global controls on a tab control. When I'm done I paste a copy of the tab control from the global to a ghost vi with separate save and cancel buttons. I can set the properties of this ghost vi for the appearance that I want. The tab controls allow me to enumerate the controls on them only (regardless of what else is on the ghost vi's front panel) and match them by label for changing the globals accordingly. The main setup program watches for the save button depressed, hides the regular vi, enumerates the controls on it, sets the non visible global's matching controls to the same value, sets them as default, and saves the global. When the application vi's are launched by the vi server they read the globals normally. This isn't exactly what you want to do and the sychronization of the control values does rely on uniquely named controls but there are some parallels that caught my attention to your post such as the loopin
g and the labels.

While it is possible to have controls with the same label text and LV seems to differentiate between their respective local variables, etc., I think it is generally not advisable.

Good luck!
0 Kudos
Message 8 of 15
(3,273 Views)
Seeing your reply to LVGuru about 12 different configs maybe the VI server editing of globals has more application for you than I first thought.
0 Kudos
Message 9 of 15
(3,273 Views)
OK, I'll give it a try - I've only only just upgraded to version 6 so I need to find out what the VI server does first! (I was surprised there wasn't an obvious "What's new/different about version 6?" in the upgrade, but there you go)

Cheers

Joolz
0 Kudos
Message 12 of 15
(3,074 Views)
Are you talking about 6.0 or 6.1? There is plenty of sales info on the new features of 6.1 at NI's web site. I haven't found any how to tutorial or more in depth info, other than the examples.

The VIServer capabilities are not new and date back to at least 5.0. Actually your using the VI Server and some of the same necessary components in your example. You use the invoke node similar to your use of the Property node with the panel reference. You have to wire in the reference to the file you want to run (or load, set defaults, save etc.), this is obtained via the Open Application Reference node and the Open VI reference node. The same reference can be used for property nodes to set/get control values just as yo
u are using them in your example.

Here's an example what I'm doing in version 6.02. It's rough because I was just completing this part when I pulled off to another project. Only the global (ALERT_ADM606M_gbl_Main.vi) and the shell file (ALERT_ADM606M_ini_Main.vi) for the first subsystem button choice is supplied. The top level vi is ALERT_Setup_pnl_Main.vi. This vi reads the setup file ALERT.SUF (Global VI with a non-standard .SUF extension). If the top level vi is compiled then the current values of the .SUF would be compiled into the built app. If a loader was compiled that launched this top-level setup vi via the VI server then the particular applications and setup files enumerated in the .SUF would be dynamic and editable from this VI, another VI or from the LV environment. This .SUF file is also used by the application's loader VI to determine what VI is run for a particular subsystem. This enables me to specify a different VI to do the same subsystem job for different e
quipment without recompiling. It also allows me to add subsystems (there's 4 more hidden buttons for subsystem setups on the top level VI).

Enjoy! I hope this helps.
0 Kudos
Message 13 of 15
(3,074 Views)
Joolz,

There is a very easy way to do this, that doesn't even have to involve saving to a file.

At the very end of execution, drop in an invoke node, wired to a VI Reference. You can be explicit and drop in a "This VI's Path" wired to the input of the VI Reference if you want also. Then, pull down the node to "Make Current Values Default". This will set the front panel values as they are, and store this with the VI. The next time it is opened, those previous values will be up on the front panel.

Hope that helps.
Message 6 of 15
(3,273 Views)