Jump to content

Recommended Posts

Hi,

When an Exe is built using application builder, an ini file is created in the same location as that of the Exe with the same name. This ini file contains some settings to be used by the Exe and is read by the Exe whenever it is run. There is an option to specify the ini file using the command promt using the command line argument 'pref'. A shortcut may also be used for the same purpose (as explained in the Labview wiki). The settings are read from the specified ini file by the Exe. Everything is fine until "Pass all command line arguments to application" option in the 'Advanced' catagory is enabled while building the Exe. If this option is enabled, the command line arguments (in this case the ini file) are not interpreted by the Exe and hence it uses the settings in the default ini file (LabVIEW.ini).

Is there any way by which the ini file, to be used for the settings, can be mentioned programmatically?

Thank you,

Ganesh Kumar

Link to comment

Do you really need to both specify a custom LabVIEW type .ini file for each run - *and* pass custom parameters to the application via the command line feature?

Let me assume that the reason for this request is just that you have not explored all the options yet, and give you some pointers (if you know of all thsi already and it's not applicable, just ignore the "instructional tone" of the following text....;-) )

The built application will always read the INI-file and the LabVIEW Run-Time-Engine will automatically use the LabVIEW-keys it recognises in the section that has the same name as the executable. If you want to use the same file for additional parameters you can, but then you'll have to write code to reads the file and handles your custom keys yourself. Such use of the ini file is a nice solution for parameters that should be somewhat configurable, but which do not require to be changed frequently. For parameters you would want to change often you should make a user interface in the application that reads and writes to separate configuration files instead. Those files should be stored in the directories dedicated by the OS to application data (on Windows this would be the Appdata or ProgramData folders).

The command line argument feature is a different way "in", with its own use case (I guess NI did not expect you to combine both LabVIEW specific arguments there, AND custom arguments, so they turn the former off if you activate the interface for the latter). There you can specify parameters more dynamically at the call of the application instead, something which is more practical to use for a limited set of parameters that you may (or may not) want to define at startup. Most people do not want to have to specify parameters in this fashion, but it can be good way to allow other applications or an administrator to individualize each session.

Link to comment

Such use of the ini file is a nice solution for parameters that should be somewhat configurable, but which do not require to be changed frequently. For parameters you would want to change often you should make a user interface in the application that reads and writes to separate configuration files instead. Those files should be stored in the directories dedicated by the OS to application data (on Windows this would be the Appdata or ProgramData folders).

As you mentioned if the application wants to write configuration to a file, the best place to keep it would be Application Data or Program Data. But the Application.ini still has to be parallel to the Application(exe). If the EXE wants to modify any value in the Application.ini(for example the vi server port) it might not have write access to the Application.ini if the EXE is installed into the program files. I feel the application.ini should not be restricted to be parallel to the exe alone. We should be able to keep it somewhere in the Application Data or Program Data and link the EXE to this Application.ini

Link to comment

I see your point and agree that it would be better to have the file somewhere you can write to it. On the other hand; how often do you need to change LabVIEW-specific settings? The user can still do it manually if required, and/or you could edit the access rights so that the program has access to write to it.

You can also store many of these in another configuration file and override the settings of the .ini file in your own code as soon as it executes. That's the case for the VI server port that you mention e.g. (It can be set programmatically using the VI Server Port property).

Link to comment

You can also store many of these in another configuration file and override the settings of the .ini file in your own code as soon as it executes. That's the case for the VI server port that you mention e.g. (It can be set programmatically using the VI Server Port property).

I haven't tried what yo said, so far. Will try it out. I think it will solve my problem :worshippy:

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.