How does the vi paths within exe work again?

[nelg87]

I thought I had this figured out but now I'm not so sure.  So I have a vi (lets call it MyVI.vi) in my project that I call dynamically so I need to know its path.  The vi is at C:\Projects\ProjectName\MyVisSubfolder\MyVI.vi  in the developpment environment.  When I build an exe the vi path is:  C:\MYEXE\MyVisSubfolder\MyVI.vi  This makes sense as I do get that vis reside in the same folder they are during development but the path now includes the executable.    

Well know I decided to change my development environment folder structure a bit (no particular reason), and my vi is now located at C:\Projects\ProjectName\DEVELOPMENT\MyVisSubfolder\MyVI.vi.  Basically I just moved all my files one folder down.  Well know my project is broken because LabVIEW says the path to my vi is now: C:\MYEXE\Projects\ProjectName\DEVELOPMENT\MyVisSubfolder\MyVI.vi  

Why is it now including all the folders above the vi??  My project resides in the "DEVELOPMENT" folder, and previously in the "ProjecName" folder.  Previously it did not include the "ProjectName" folder just he subfolder where the vi resides, why is it different now?  Has anyone run into this problem?

[crossrulz]

That sounds like a link of a relative path got broken.  Did you update the project to have the VI loaded from the new location?  Did you do a mass compile of all of your code to make sure they are looking for the vi in the new location?

[Bob_Schor]

Presto, you've just discovered the Tremendous Virtue of using Static VI References.  Here's what you do:  Instead of loading a path to your VI (in a Constant or Control) into the Open VI Reference, a path that depends on whether you are in Development or Execution mode, you drop down a Static VI Reference, right-click it and choose "Browse for Path" until you get to the VI you want (and, as a bonus, if your VI has an Icon that you made for it, that Icon appears on the Static VI Reference), then wire the Reference to a Property Node and use the VI Path property to wire to your Open VI Reference.  This code works, whether you are in Development or Executable mode (it doesn't care, it gets the right path anyway).  No muss, no fuss.

Bob Schor

[nathand · Accepted solution]

The EXE will duplicate as much of the folder structure as necessary to get to the point where all the contained files share a common path. This can also be described as enough of the path to allow relative paths to work (that is, if your VI references as file at ..\..\Another_Folder\subVI.vi, the EXE will include at least two levels above the current vi so that the ..\..\ path is valid). Sounds like when you moved your development folder, you continued to reference some VIs that didn't move, and now in order to preserve the relative path structure the EXE needed to include a larger portion of the path.

[nelg87]

I am familiar with static vi references but I can't use them in this instance.  I have a custome test executor application and it calls different vi's depending on the type of hardware or test being run at the time.  These vis are called dynamically by passing in the vi path as a string and using the "open vi" reference.  Thanks for your input though.

[nelg87]

I just did a mass compile of my project.  And before that I made sure I'm not referencing anything on the previous location and the path still includes the extra folders.  I guess it has to do with the common path like someon mentioned on this thread.  But the thing is that nothing from the previous path is referenced.  I basically added a folder to the path and moved everything in it.  I don't understand why it would change 😞  I guess I can just moved everything back I just wanted to understand why this is happening.

[nelg87]

Your response made me go back and revise ALL files paths including dependencies.  I found a file inside an LLB in the dependencies that was being loaded from a different directory that match the common path that I was seeing in the vi path in question.  I went back to reference the correct local copy of this file, recompile, and my problem is fixed!  Thanks so much!  The wording "common path" was what really made the difference.  Thanks!