Example Code

Current VI's Path (VI or exe)

Code and Documents

Attachment

Overview

This Vi returns the path of the current VI, executable or packed project library as well its installation directory

 

 

Description

If you have ever built a VI that uses the native Current VI's Path function, then you have most likely had to deal with unexpected behavior after you build your VI into an executable or into a packed project libtrary. The VI works great in the development environment, but when you build it and run it as an executable, you may see any number of problems which may include, but not be limited to errors when performing File I/O.

  

The Current VI's Path (VI or exe or lvlibp) VI is a drop-in replacement for the native Current VI's Path function and it will return the path of the code running in the development environment or as an executable!

 

 

Steps to Implement or Execute Code

Run the included example VI, executable and test application inside the packed project library to see how you can use this functionality in your applications.

 

 

 

Requirements

LabVIEW 2014 (or compatible)

 

 

Additional Information or References

 

The Current VI's Path (VI or exe or lvlibp) VI gets the path to the VI that called it and searches that path for ".exe" or ".lvlipb". If either is found in the path, then the Current VI's Path (VI or exe or lvlibp) VI strips the path to obtain the installation directory. If neither is found, then the Current VI's Path (VI or exe or lvlibp) VI strips the path once to obtain the VI's installation directory.

 

In either case, the Current VI's Path (VI or exe or lvlibp) VI returns the VI, executable or packed project library installation directory and the Full Path to the VI, executable or packed project library.  You can use this information in your application to easily access sub folders of the installation directory by using the Build Path function to append the sub directory's name to the installation path returned by the Current VI's Path (VI or exe or lvlibp) VI.

 

 

Block DiagramCurrent VI's Path (VI or exe or lvlipb)_LV2014.png

 

 

Example code from the Example Code Exchange in the NI Community is licensed with the MIT license.

Comments
Todd S.
NI Employee (retired)
on

Thanks for posting! When you have time, could you please rename your attachment to include the LabVIEW version, and also include a screenshot?

Todd S.
LabVIEW Community Manager
National Instruments
Mark.Ridgley
Member Member
Member
on

Hi, Todd

As you requested, I have posted block diagram screenshots as a new section in the body of the document and indicated the LabVIEW version used to develop this VI. Let me know if you need anything else.



Andrey_Dmitriev
Active Participant
Active Participant
on

Hi, Mark,

Why do not use Application.Kind property node? Much more easier for programming, isn't?

Andrey.

Mark.Ridgley
Member Member
Member
on

Hi, Andrey

The issue that the Current VI's Path (VI or exe) VI is designed to address is that of user expectations when using the native Current VI's Path function. In my experience, when users place the native Current VI's Path function in their code, the expectation is that the function will return the correct path to their code and that the native Current VI's Path function should just work -- regardless of if the code is being executed in the development or run time environment. This is apparent when you read posts such as the one referenced above.

Many times, users write code using the native Current VI's Path function, build that code into an executable and are surprised to find that it does not return the correct path when they run it.

The difficulty arises when your code is designed to write or read from files that are in locations relative to the directory where the VI or executable is located. The user must have a method that can determine the owning directory of the VI or executable.

In order to determine the VI's or executable's owning directory using the app.kind property node requires first that the user is aware of this method for addressing the problem and second that the user add the following steps to their VI code (See the screenshot in the section titled "Using the App.Kind property node to determine the current VI's or executable's owning directory" above):

  • Open application reference
  • Place app property node on the diagram
  • Read the App.Kind property from the property node
  • Get the current VI's path using the native Current VI's Path function
  • Test to see if the value returned from the property node is "Run time System"
  • If the value is "Run time System", strip the path returned by the native Current VI's Path function twice to get the executable's owning directory.
  • If the value is not "Run time System", strip the path returned by the native Current VI's Path function once to get the VI's owning directory.
  • Close the application reference

In contrast, to determine the VI's or executable's owning directory using the Current VI's Path (VI or exe) VI, the user only needs to replace the native Current VI's Path function with the Current VI's Path (VI or exe) VI. I think that this option is easier to implement from the user's perspective (See the screenshot in the section titled "Using the Current VI's Path (VI or exe) VI to determine the current VI's or executable's owning directory" above).

I believe that the Current VI's Path (VI or exe) VI meets the user expectation that they can place a single function on their block diagram that returns the correct path to their code regardless of if their code is being executed in the development or run time environment.

Thanks for posting.

Angela M
Active Participant
Active Participant
on

This is a nice example.  As of LabVIEW 2009, you may also find the Application Directory VI (on the File Constants palette) useful.  It returns the path to the directory of the top level VI if the VI is not in a project.  If you are running in the development environment in a project, it returns the path to the directory containing the lvproj file and if you build this into an application it returns the path to the folder containing the exe or shared library.