11-17-2008 02:19 PM
I am working on a generic subvi to save and restore the main VI control settings when the program starts and ends. I can't seem to find a way to identify the particular type of control. For example I can generate a list of front panel booleans but I can't tell if they are buttons, switches, rockers, etc. There is no point in saving a STOP button setting but I would like to save check box settings. I suppose some sort of naming or description convention would work but I am hoping for a more elegant and foolproof solution then that.
Attached is the block diagram I have been working on which builds lists of ClassID's, Class Names and Labels.
Any suggestions on how to identify the particular type of control within a class?
11-17-2008 02:30 PM
11-17-2008 02:36 PM
You might want to look into the OpenG "VariantConfig" library. This has some VIs that will pull the data from your front panels controls and save them in an ini-file format from which you can restore state later. It will save you quite a bit development time.
http://wiki.openg.org/Main_Page
It won't store e.g. switch vs LED indicator, as that's control appearance and not control value.
11-17-2008 03:11 PM
Your right, the properties and values are the same but I was hoping to make my program more selective. For example if I have a momentary pushbutton on the front panel then it doesn't make much sense to store its value at program end and restore it at program start. It probably wouldn't hurt anything but if there are a lot of these types or similar controls then it could slow things down a bit and store a lot of unnecessary data.
In my application I plan to use check boxes and numeric controls to allow the user to customize the program. These setting are to be saved so that the user doesn't have to reenter them again. I was also hoping to keep the subvi general so I could use it in other projects.
11-17-2008 03:23 PM
If the settings you want to save are all or mostly used as "setup" controls and typically do not change after the real work of the program starts, you could put them on a Setup tab of a tab control. Then you could get the reference to the tab control and find the controls only on the Setup tab. At most one or two controls (like Enter) on that page would be ones you would not need to save. The Start/Pause/Resume/Stop controls and controls which modified displays as well as graphs and other data and status indicators would be on the Run tab.
It has some limitations, but might be workable.
Another idea: Put a list of controls to be saved in the config file. This would allow the programmer or a high level user to change what was saved without changing the program. And the program does not need to be smart enough to figure out which control values need to be saved.
Lynn
11-19-2008 08:17 AM
I ran into the same challenge and ended up adding an exception file that sits next to the config file. The exception file contains a list of the controls that should NOT be saved/restored. This method has been in use in my shop since LV 6.1 and has served us well. And since you are "digging around in this pile" you may want to take a look at my Nugget on using Control References to Save/Restore from file for another way of addressing this challenge.
Just trying to help,
Ben
11-19-2008 09:23 AM
Thank you for your assistance. From the responses received I gather that my suspicions are correct and that there is no way to programatically determine the specific type of control (switch, button, check-box, etc.)
A few good workaround suggestions were proposed. I like the idea of grouping the settings on a tab and only saving/retrieving those setting. I am also intrigued with the idea of using an exception file and will be exploring that solution as well.
Again, Thanks to all for your help.
11-19-2008 09:39 AM
drog wrote:Thank you for your assistance. From the responses received I gather that my suspicions are correct and that there is no way to programatically determine the specific type of control (switch, button, check-box, etc.)
Oh, I wouldn't say that. There are ways, if you don't mind being sneaky.