Example Programs

cancel
Showing results for 
Search instead for 
Did you mean: 

Current VI's Path (VI or exe)

Overview

This VI returns the path of the current VI or executable 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. 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) 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 and executable to see how you can use this functionality in your applications.

 

 

 

Requirements

LabVIEW 2012 (or compatible)

 

 

Additional Information or References

 

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

 

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

 

 

Block Diagram

 

 

BD.PNG

 

**This document has been updated to meet the current required format for the NI Code Exchange.**

Comments
Active Participant Todd S.
Active Participant

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
Member Mark.Ridgley Member
Member

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.



Active Participant Andrey_Dmitriev
Active Participant

Hi, Mark,

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

Andrey.

Member Mark.Ridgley Member
Member

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.

Active Participant Angela M
Active Participant

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.