Saving/loading configurations

[m-s]

I have a VI with a large number of front panel inputs (numeric).

Is there a way to save the current front panel state to a configuration file and then load it later in a different session, to avoid having to do this. Save value as default is not an option as multiple users of the VI have different values for the parameters for measurement.

I envision a mechanism in which each user could save a configuration file and then load it when needed.

[nitad54448]

hi

you need to use ini files; in LV it is possible but difficult. A better way is by using openG library functions. Make a seacrh on the forum; I saw this discussed before.

N

[Mark_Yedinak]

---

@nitad54448 wrote:

hi

you need to use ini files; in LV it is possible but difficult. A better way is by using openG library functions. Make a seacrh on the forum; I saw this discussed before.

N

---

It actually isn't that difficult. The OpenG is nice since it will use a cluster and save/retrieve it using only the cluster. The down side is that it does some things that make the ini file not as useful if a person will hand edit the file. We use a method that will require some minor editing since it is specifically type to a typedefed cluster, but the nice part is that you can write the string value of an ENUM to the config file. We also have methods so that you can store a relative path in the ini file. By using a custom method like the ones I have attached it is pretty straightforward to add new items to the list of things you want to read. It also gives you a way to format the data in the ini file in a more user friendly manner. The OpenG method writes ENUMs as a number. It is harder for users to remember the mapping of the number to the ENUM in the application.

To implement the save portion for the example I included you use the same technique but write the ini file rather than read it.

[nitad54448]

---

@Mark Yedinak wrote:

It actually isn't *that* difficult.

---

you're right, not *that* difficult but still I find it more that the openG (at least when you don't want the user to change the ini file...)

thanks for the example files....

[Mark_Yedinak]

---

@nitad54448 wrote:

you're right, not *that* difficult but still I find it more that the openG (at least when you don't want the user to change the ini file...)

thanks for the example files....

---

Yes, it is a bit more involved than the OpenG. If a person will not be modifying the ini file I will generally use the OpenG. If I want to create a more user friendly ini file I use the example I posted above. Either way you now have two methods you can use.

[m-s]

Hmm.

I am a stranger to Open G.

I would have thought that LabVIEW would have an easy way of doing something like this, given how common the situation I describe is. I am planning on distributing a standalone executable.

[Mark_Yedinak]

Native LabVIEW provides primatives for working with ini files. The OpenG library put together a nice vi that did a lot of teh work for you. As complete as LabVIEW is NI can't write all of your code for you. They do an excellent job of providing you th ebuilding blocks though.