LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Getting .vi directory list from LabVIEW executable internally


@Alexander_Sobolev wrote:

I can open reference to VIs always included into exe by their path inside exe. 


Yes if you know the path to the VI relative to the EXE.  I'm saying you cannot always know that.  Let me try again.  For any given EXE that I have a VI running in, I want to know the names and absolute paths to all VIs inside that EXE how can I do that?  The best option so far, is as I mentioned to run a pre-build VI that looks at the relative paths to the project, writes that to a file, and then when the EXE runs, use this information and hope that the relative path from source to project, is the same from VI to EXE.

 


@Alexander_Sobolev wrote:

Then it depeds only on 8.x layout checkmark.


Yes the thing I don't have control of when I am not the developer and instead am providing an API for others to use.

 


@Alexander_Sobolev wrote:

Relative path from main vi is the same as in project


Is there NI documentation stating that this will always be the case?  Because I've built EXEs where this wasn't true, with things like mapped network drives or source files being not on the same partition, and a few other cases I couldn't explain.

0 Kudos
Message 11 of 14
(1,693 Views)

Thanks for the response.

 

I was able to resolve the problem. The cause was basically the same as you mentioned. There were actually not just one but several .vi's in the .exe that it could not locate even though it had no problems finding them in any of the previous builds. What happened is that I added a new subvi to the main vi of the project but did not put a copy of this new subvi in one of the current project's folders. So it was pointing to the file in the folder hierarchy of another project and listing it as a dependency. Once I placed a copy in the current project's folder hierarchy and removed the dependency to the other project's subvi the issue resolved. But what I don't understand is why it just didn't report an error that it couldn't find this one particular .vi and instead reported that it could not find any of the .vi's.

 

That resolved my immediate problem but I still want to figure out if there is a way to get the directory listing directly from the .exe as a debugging tool.

0 Kudos
Message 12 of 14
(1,673 Views)

I greatly appreciate everyone's responses to my question. It will take me some time to work through them though. Thanks again.

0 Kudos
Message 13 of 14
(1,666 Views)

So I made a simple example to show you the difference.  If you have a VI that is a dependency but is in another directory or maybe a different drive letter, the EXE will create a virtual directory structure within the EXE to mimic the actual layout of your project.  So i have a Main.vi that shows it's file location and a subVI that gets it's own file location and shows it on the Main.vi front panel.  Notice the path is the same up to Application.exe and then it splits into Z drive and C drive.  

different location.PNG

 

If I move the subVI into the project directory, the path to both VIs are exactly the same.  same location.PNG

 

In the first case with the files in different directories or drives, if you are calling these VIs dynamically, you can't simply call desktop.vi because you have to take into account that the relative path is now different.  Also, every file included in the EXE has an overly long file path because, in order to find a common directory structure, the build engine has to go to the point in the tree diagram where both files can be accessed, in my case it is back to drive letters.  And all it takes is one file that is out of place and this will happen (as you found out).  

 

Hope this helps.  

aputman
0 Kudos
Message 14 of 14
(1,660 Views)