LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

.ini file use created by EXE

Solved!
Go to solution

First let me state I have a thorough understanding of .ini files and the need for them.  My question is related specifically to the .ini file that is created with the executable.  I have searched the forum but have not found any instance of my question specifically.  After install, the .exe and .ini are placed in my working directory in Program Files, which I expect.  The .ini file that gets created is the attached. 

Now I would like to point to a different .ini that stores some control settings.  I have done this in the App Builder under Advanced>>Use Custom Config File.  That's fine and dandy, but the network, web, etc settings that were created in the original .ini do not get included in my new .ini.  So my option is to use a separate .ini file with my control settings plus the one created by the .exe.  This seems redundant.

 

My question is: Does my executable do anything with the .ini file that is created when it starts to run?  Would I be OK NOT to have the attached items included if I wanted to point to a custom .ini file?  Why create an .ini file with these specific settings if the .exe does nothing with them?

The only article I have found is this one

http://digital.ni.com/public.nsf/allkb/5467F7D7895835C186256FAF00600A21?OpenDocument

but it doesn't explain what the .exe does with it, if anything.  I assume you have total control over the .ini and there is nothing "automatic/behind the scenes" going on here.

Thanks in advance for your assistance.

-----------------------------------------------------------------------------------------
Reese, (former CLAD, future CLD)

Some people call me the Space Cowboy!
Some call me the gangster of love.
Some people call me MoReese!
...I'm right here baby, right here, right here, right here at home
0 Kudos
Message 1 of 6
(8,384 Views)

Strictly speaking, your own extra config data should be kept in the Program Data directory. XP doesn't enforce this, but windows 7 has introduced steps to encourage this practice. (e.g. running a program as administrator)

The system directory VI in the files constants palette is useful for getting default/user defined paths:

 

public app data.png

 

The default (private data) ini file in the root directory is used to pass arguments to the application when it opens. Similar to making a C app open with main(argc, argv[]*). Keys in the ini file which are used, include paths to items in the \data directory, paths to DAQmx files, and information regarding remote debugging,

 

A nifty one to add is overriding the default text size - useful if compiling a code in windows 7 (15pt) for use in windows XP (14pt)

AppFont="Arial" 14
SystemFont="Arial" 14
DialogFont="Arial" 14

_____________________________
- Cheers, Ed
0 Kudos
Message 2 of 6
(8,376 Views)

Hi Mo,

 

LV-Runtime is reading that ini file to set it's own properties (like for VI server and so on).

It does not magically read your own keys and applies them to some controls or whatever. You have to read the ini file on your own to apply the settings to your controls...

Best regards,
GerdW

using LV2011SP1 + LV2017 (+LV2020 sometimes) on Win10+cRIO
0 Kudos
Message 3 of 6
(8,374 Views)

@GerdW wrote:

Hi Mo,

 

LV-Runtime is reading that ini file to set it's own properties (like for VI server and so on).

 

So if I understand you correctly, the settings that are created by the App Builder are required for the LV run-time engine,correct?

It does not magically read your own keys and applies them to some controls or whatever. You have to read the ini file on your own to apply the settings to your controls...

 

Yes, I understand how the .ini works, my question was regarding those settings that get created with the App Builder.  So does this mean I will require a separate .ini for my controls?


 Thanks for your reply.

 

 

-----------------------------------------------------------------------------------------
Reese, (former CLAD, future CLD)

Some people call me the Space Cowboy!
Some call me the gangster of love.
Some people call me MoReese!
...I'm right here baby, right here, right here, right here at home
0 Kudos
Message 4 of 6
(8,361 Views)
Solution
Accepted by MoReese

Why would you point the app builder at a custom INI file if you're going to have to read the tokens in it manually anyway?  The reason for using a custom INI file in the app builder is so that you can include run-time specific settings (VI server port, access list, etc) that are different than the settings that the LabVIEW development environment is using.

 

You do not need the keys in the INI file in order for your application to execute (as demonstrated by the fact that if you delete the INI file, your exe will still run, creating a new INI file with defaults).  If you leave out the default keys, the application will add them in on the first run anyway.

 

You can store your own data in the same INI file that the executable uses; just put the keys in a different section.  The LabVIEW Config File VIs format INI files slightly differently (for example adding spaces around the = sign) but I haven't seen this cause problems.

0 Kudos
Message 5 of 6
(8,356 Views)

Thanks for the response Nathand.  That answers my question.

-----------------------------------------------------------------------------------------
Reese, (former CLAD, future CLD)

Some people call me the Space Cowboy!
Some call me the gangster of love.
Some people call me MoReese!
...I'm right here baby, right here, right here, right here at home
0 Kudos
Message 6 of 6
(8,336 Views)