Support File Settings and Relative Paths for Executables

[Will_S.]

Overview
This example demonstrates the file paths and relative paths of VIs called from within an executable.

Description
With this VI, you can see the file paths and relative paths of VIs when they are called from within an executable. It also demonstrates how to call VIs dynamically from a support directory, and what file paths is output from VIs when set to the various destinations as allowed in Support File Settings.

The VI performs the following:

• Displays The Top Level VI, and the paths of each SubVI.
• Creates a directory, dynamically loads a VI, and places the VI in the directory.

Requirements

• LabVIEW 2012 (or compatible)

Steps to Implement or Execute Code

• Download the .zip and unzip the contents into one folder
• Run the EXE Application
• View the different indicators on the front panel to see the different file and relative paths

Additional Images

Block Diagram

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

[cirrusio]

Thanks for this Will.  Trying to build a exe with a compiled help file has been maddeningly difficult because the path structure is not entirely clear to me.  Regarding this post, I do have one suggestion - explain to the user what is happening and why.  Reading the help, this is not clear (at least to me).

Anyway, thanks for posting this.  Matt

Edit: It might also be beneficial to show how this would work using both the Development and Runtime systems.  You can make it so this VI is executable in both simply by adding the proper logic using the Property Node for the Application with the method Kind invoked.

[CodePeasant]

This is good for the effort. And in most cases it works well.  Consider what happens when your Top Level VI exists in a relative path itself: http://forums.ni.com/t5/ideas/v2/ideapage/blog-id/labviewideas/article-id/12288/page/1#comments

Specifically when your build includes VIs above the Top Level VI path.  That sounds silly, but when you include files from a directory above the Top Level VI path LabVIEW application builder creates the absolute path such that all VIs included in the build are relative to the absolute path:

Assume a.vi calls b.vi. If a.vi is in a directory called Code\Projects\Project1 and b.vi is in a directory called Code\Libraries\Lib1 the Application Builder will strip the absolute path of both VIs as far as they are the same.  Then the relative path for each VI starts at that directory.  a.vi would look like this Application.exe\Projects\Project1\a.vi and b.vi would look like this Application.exe\Libraries\Lib1\b.vi.  I learned this awful truth the hard way.

Why would anyone do this type of code development?  Code reuse from a common code repository.

In LabVIEW 8.x files were stored in a flat file format.  Calling VIs dynamically meant using the VI name only. Relative paths must now be set up from the common path of all VIs included in the build.  LabVIEW help file for Building Applications Checklist glosses over this detail causing you to assume the Main Top Level VI path always exists as one level below the application file path within the executable.