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 Diagram
Example code from the Example Code Exchange in the NI Community is licensed with the MIT license.
Thanks for posting! When you have time, could you please rename your attachment to include the LabVIEW version, and also include a screenshot?
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.
Hi, Mark,
Why do not use Application.Kind property node? Much more easier for programming, isn't?
Andrey.
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):
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.
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.