LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Best way to build a path when "Application Directory" returns VERY different locations

Solved!
Go to solution

Hi there,

 

I'm having a problem building a path to my config file because it gets called from TestStand, allow me to explain. Normally for LabVIEW development I have a disk hierarchy like this:

 

- Project Folder

     - Project.lvproj

     - Config Files

          Config.ini

 

Then when I use "Application Directory" I get back "Project Folder" and can easily build the path to my config file. When I build the executable, I don't need to change anything, and the disk hierarchy looks like:

 

- Application Folder

     - Application.exe

     - Config Files

          Config.ini

 

Now the application directory is "Application Folder" but I still build the path to the config file the exact same way.

However, when I call the code from TestStand, the application directory is that of the TestStand executable. I forget exactly what it is, but for the sake of discussion let's say "C:\Program Files (x86)\National Instruments\TestStand\" which is nowhere near my config file...

So should I get the path of the VI, and strip the path until I get back up to the .lvproj directory? This could cause problems if I ever change the disk location of the VI that loads configs. Any other suggestions?

 

Thank you,

Gregory

Message 1 of 8
(7,566 Views)

Instead of using "Application directory" you may wish to use "Get System Directory".

 

There's 14 options on which directory to get and it's completely independent of where the file runs from.

 

It will be slightly less convenient as it does mean that the INI file will be stored in a directory different from the VI or EXE.

Message 2 of 8
(7,554 Views)
Solution
Accepted by topic author Gregory

Does the Current VI's Path not return the directory of the built EXE?  You'll have to make a case structure that if the application is run from a project, use this path.  Otherwise use that path.  I've never used Teststand so I'm not familiar with it. 

aputman
------------------
Heads up! NI has moved LabVIEW to a mandatory SaaS subscription policy, along with a big price increase. Make your voice heard.
Message 3 of 8
(7,541 Views)

In TestStand, you can get the sequence file's path and pass that into your VIs to find your config file.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 4 of 8
(7,518 Views)

@aputman wrote:

Does the Current VI's Path not return the directory of the built EXE?  You'll have to make a case structure that if the application is run from a project, use this path.  Otherwise use that path.  I've never used Teststand so I'm not familiar with it. 


No, it returns the VI's location within the executable. I am trying to use this case structure idea, but the problem is that RUN_TIME_ENGINE==True when running from TestStand or from an EXE, but the paths will be different

0 Kudos
Message 5 of 8
(7,512 Views)

@crossrulz wrote:

In TestStand, you can get the sequence file's path and pass that into your VIs to find your config file.


Thank you for the idea. The way all of our LabVIEW modules are stored on disk is in an uncontrolled folder and controlled folder, and then in the folder corresponding to the module's internal tracking number followed by revision. I'm afraid if we changed the revision or go from uncontrolled to controlled then it will also cause the path to be incorrect.

0 Kudos
Message 6 of 8
(7,508 Views)

For now a quick fix is to use the Application App.Name property. For development environment it will be "Labview.exe", for TestStand it will be "SeqEdit.exe", and for a built application it will be "[Application Name].exe". I just made it so the built application uses the Application Directory and all other options it will be relative to the VI location. Not great if I change the name of my built application or rearrange my VIs on disk relative to the config file, but I don't plan on actually using the built executable, I just build it every once in a while to check runtime environment behavior.

0 Kudos
Message 7 of 8
(7,501 Views)

An additional option could be to check the "Execution.State" property of the MAIN VI.  I have not used Teststand, but I suspect that the VI's execution state when called from Teststand will be reported as "Run" as opposed to "Run Top Level" when running on its own.  You could use that check along with the "App.Kind" property to adjust config pathing for all of your execution cases.

Message 8 of 8
(7,417 Views)