Serial port number savings in .ini file (executable with application builder)

[Yamaeda]

---

@daveTW wrote:

Btw. why doesn't work the snippet of pincpanther on my system (LV2019 32bit) ?? Am I the only one?

---

Depending on your web browser you might need to Save image to disk before dragging it to a block diagram.

/Y

[mabaig]

Hi guys

Another option is to have an ini-file in your project and have it copied there through the Installer

will the *.ini file still be installed with *.exe even in other PC's once we include??

This *.ini  might not be available in the location that we are providing while creating installer(in installer properties) in other PC's of course. Does the Installer keep it compressed within it and install included files with *.exe where ever we install it? I didn't the the chance to check this.

And DaveTW. If we do like you say doesn't we have to create the whole  *.ini again in False??

With all the keys and  sections?? Bcoz the file I am trying to include contains couple of sections and Bunch of keys. Creating these again would be a trouble again .

Thanks and Regards 

Baig

[RavensFan]

Yes.  The ini file is a part of the installation package.

---

@mabaig wrote:

And DaveTW. If we do like you say doesn't we have to create the whole  *.ini again in False??

With all the keys and  sections?? Bcoz the file I am trying to include contains couple of sections and Bunch of keys. Creating these again would be a trouble again .

---

"Because".

You can create the .ini file.  Or you just populate your globals or action engines or controls with default values instead of the values that would have come from the .ini.  I usually have a Save Settings button in my program to save the settings to the .ini in the event something changes.

As for "creating these again", you would only do it once.  Wrap that code in a subVI so you can call it "again" from other places.  Create once, use multiple times.

You wouldn't even need to do multiple sections and keys if you want to create a new ini file filled with default values.  Just create a diagram string constant that has the syntax of an ini file and write that out to a text file.  Open file, write the big string constant, close file.

[daveTW]

For me this works very well:

1. After program start, I call "Load Settings.vi", which has appropriate default values wired to the "Read Key" node. I store these values locally (to the cluster, which is stored in my shift register of my main while loop).
2. I use the locally stored values, while the program runs. This is fast.
3. While program stop, I call "Store Settings.vi", which stores all locally stored values to the INI- file.

So you have to keep track in your "Load Settings.vi" & "Store Settings.vi", which have to correspond to each other (same typedef- cluster as output/input, same number of Read Key / Write Key nodes)

[daveTW]

To elaborate this a bit:

With this structure you can set default values in the typedefed cluster constant and wire each value to the "default value" input of the "Read Key" node. You can have as many cases as you want to read every single config-file entry and you can easily expand the number of settings with the "Duplicate Case" instruction of the case-structure context menu.

The while loop is aborted automatically after the last case with the default case. With duplicating one existing case LabVIEW takes care for the numbering of the cases.

And storing is the same vice versa, so every case in "Read Settings.vi" will have a corresponding case in "Store Settings.vi".

Often I create the Read-VI first and derive the Store-VI from it, using Save as -> Open additional Copy

[crossrulz]

---

@daveTW wrote:

With this structure you can set default values in the typedefed cluster constant and wire each value to the "default value" input of the "Read Key" node. You can have as many cases as you want to read every single config-file entry and you can easily expand the number of settings with the "Duplicate Case" instruction of the case-structure context menu.

---

I use a FOR loop to read through my configurations.  I can either use the Get Key Names to get the list of keys from the configuration file and iterate other those or supply my own array.  Then the case structure is keyed off of the key.  This is more self-documenting.

[mabaig]

Hi guys,

Thank You very much for the help

Actually I wanted to configure VISA config.vi inputs using the *.ini file 

I would change the required parameter ( such as port number, parity bits, stop bits, timeout, etc) in *.ini file and open the application which should be taking all the changes from the *.ini file.

I wanted this kind of process because this application will be running on different computers some of which will not have LabVIEW. And for different computers most of the time Port Numbers will be different. So that I will just open the *.ini file and change the same before launching the application.

What I did considering the Ideas I have got from You guys is, I included the NIvisa config file from NI main folder(which holds the config details) and given one specific location(i.e., C:\Program files(X86)\appfolder) in my Main VI, so that usually when installed , we install in C:\Program files(X86)\appfolder location and with installation the *.ini file will be extracted in the same folder and it will read it automatically without any file missing error. The problem with this is, if application is installed in different location than C:\Program files(X86)\appfolder this idea would not work. 

[daveTW]

Hello mabaig,

a very long time ago I made myself a VI which helps me with exactly your described task. It is a dialog window, which does all the INI reading an writing and shows the settings user friendly (if you like to, there is a boolean input "don't show dialog"). I attached a zip file containing this VI "VISA COM-Dialog V2.vi" and its SubVIs. (You will see that I didn't program the Key-Read and -Write like I suggested before - this shows, how old this dialog-VI is ) The UI and some other strings are in german, perhaps you want to translate it yourself.

The other point is still the location of the INI file. As pincpanther showed here it's better to store this file in the public application data folder. The exact location of this folder is controlled via some Windows registry- settings and can vary from machine to machine. But the "Get System Folder"- VI hides this and delivers the correct path. The use of some subfolders of \Program files(x86) is not a good idea, becaus if you log in with limited permissions (e.g. not being a local administrator) you don't have permissions to programmatically write to the INI file.

If you want to put your predefined INI file to this public application data folder, you can do this via the installer, as I will show you:

The installer can create the folder on installation time. You define this on this installer panel.

2nd step.

But if you check for the INI file on program initialization and create it from your default cluster if not present, you don't have to bother the installer with this and won't have any issues with an executable which isn't installed, but simply started from whichever location you want.

[mabaig]

hi daveTW,

That's an awesome work.

What I thought is it would be easier to have it in the same folder of *.exe so that anyone using would right click on the desktop shortcut icon and go to target location and change the required parameter. 

Thanks Alot

Regards 

Baig

[daveTW]

I wouldn't let any user fiddle around in my *.ini file. Too much error checking...