How to handle configuration file information inside large apps?

[Olaf_Stetzer]

Hi all,

I am wondering if there is an elegant way to handle configuration information - preferably read from an ini-file - inside a large application.

Specifically I have the following problem - or lets say inconvenience:
In my application I have currently around 30 config file entries in 5 sections. Data types are varying. I now want to pass these information in an elegant way to sub-vi's in such a way, that a change in the data format of the config file does not require me to change IO-structures of tons of sub-vi's. Currently each section is read into a cluster and the cluster passed over to sub'vi's. But this is very unflexible if I need to change the format of an entry or even add/delete entries. I am not sure but maybe using references instead of the clusters themselves would make things a bit easier. But even then the read routine is still very large and crowded but it seems that there is no way to use a loop over all elements of a section to make this more elegant?

Any ideas appreciated!

Thanks,

Olaf

[Olaf_Stetzer]

Just to add one idea I had: Is it possible to pass over the pointer to the config file to sub-vi's so each sub-vi can read just the information it needs? Problem: I need to branch that pointer to several sub-vi's in parallel and it might be possbile that different vi's try to acces the config file simultaneously. Could that cause any problems? I only need to read information, I have no plan to write back files at all!

Cheers,

Olaf

[pincpanter]

A very useful technique to stay updated automatically when datatypes change is making clusters typedefs (right click on the cluster control, choose Advanced->Customize, then save the customized control as a Typedef). A Typedef is a custom data type; when you change a Typedef, all controls and constants connected to the datatype are automatically updated.
Typedefs should be defined in the early stages of the development process.
In your case, if you create a Typedef for each cluster/section, you will need to Replace every occurrence of a control or indicator or constant into the newly created Typedef before being able to enjoy the automatic update. After that, if you add/remove/change a member in a Typedef and choose File->Apply changes when the datatype is open, you get the desired effect in all related vi's.

[Olaf_Stetzer]

---

@pincpanter wrote:
A very useful technique to stay updated automatically when datatypes change is making clusters typedefs (right click on the cluster control, choose Advanced->Customize, then save the customized control as a Typedef). A Typedef is a custom data type; when you change a Typedef, all controls and constants connected to the datatype are automatically updated.
Typedefs should be defined in the early stages of the development process.
In your case, if you create a Typedef for each cluster/section, you will need to Replace every occurrence of a control or indicator or constant into the newly created Typedef before being able to enjoy the automatic update. After that, if you add/remove/change a member in a Typedef and choose File->Apply changes when the datatype is open, you get the desired effect in all related vi's.

---

Thanks for this advice, sounds like a very helpful feature. I will use this whereever it is possible. But to my original question: Is this the most elegant way to pass over configuration information to sub-vi's? This method still requires a rather bulky read routine to read and store all the information into the various clusters....

Olaf

[tst]

If you go to the OpenG site, you can download the Variant Configuration package which will give you VIs which can save and load clusters to INI files. Very convenient.

[Olaf_Stetzer]

---

@tst wrote:
If you go to the OpenG site, you can download the Variant Configuration package which will give you VIs which can save and load clusters to INI files. Very convenient.

---

Thanks, I will try this out today. One question though: Are these libariries pure labview-code? I am asking because the code in question needs to be uploaded to a compactFieldpoint and this guy does not like windows dll's.

Olaf

[Kallis]

OpenG libraries are LabVIEW files. You can manage and download OpenG packages using VIPM

Message Edited by Kallis on 02-16-2007 02:09 AM

[Olaf_Stetzer]

---

@tst wrote:
If you go to the OpenG site, you can download the Variant Configuration package which will give you VIs which can save and load clusters to INI files. Very convenient.

---

Thanks again, just downloaded the library and it seems to be exactly what I was looking for. 🙂 On further question: Is there any example code that helps me impleneting the variant cluster into my app? I have some ideas how to manage this but some further documentation would help a lot! E.g is the following code correct use?

Thanks,

Olaf

[tst]

I can't look at your code, but you basically need to use the Variant to Data primitive to convert the variant back to your cluster. You can see a simple example here (which contains all of the OpenG code).

This library is pure G, but you should test it on an RT target before embedding it in your code, because RT does not support some things even if they are native G. I think this should work, though.

[Olaf_Stetzer]

---

@tst wrote:

I can't look at your code, but you basically need to use the Variant to Data primitive to convert the variant back to your cluster. You can see a simple example here (which contains all of the OpenG code).

This library is pure G, but you should test it on an RT target before embedding it in your code, because RT does not support some things even if they are native G. I think this should work, though.

---

Sorry, I probably should have converted the vi from 8.20 to 8.0, but here is the screenshot: