LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Find files in .exe

Solved!
Go to solution

In ye olden days you could list files in an .exe and find them, but since many years now you cannot, so what's the best way to find them? They're not listed in the ExportedVI-list?

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 1 of 7
(457 Views)

It depends on what you really need. If you just want to get a list of the loaded VIs inside of executable, you can use the *All VIs Paths in Memory* Property Node. However, if you need to "disassemble" the executable (without source) into separate SubVIs, you can use pylabview (some Python knowledge is required).

Screenshot 2025-12-12 15.48.44.png

 

0 Kudos
Message 2 of 7
(396 Views)

@Andrey_Dmitriev wrote:

It depends on what you really need. If you just want to get a list of the loaded VIs inside of executable, you can use the *All VIs Paths in Memory* Property Node. However, if you need to "disassemble" the executable (without source) into separate SubVIs, you can use pylabview (some Python knowledge is required).

Screenshot 2025-12-12 15.48.44.png

 


That's just the problem, if you include a class in Always included, it doesn't list with that node until you've done a Open VI, which i'm (or rather a collegue) is missing the path to.

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 3 of 7
(367 Views)

LV maintains the relative paths inside the EXE (with vi.lib stuff going in a 1abvi3w folder). The exact structure of an EXE is a bit more complicated, but you can see this behavior if you look at the build folder while the build is happening (although that might end up messing your build up).

 

The practical upshot of this is that if you want to include something in the EXE without loading it statically and then load it, you can simply place a VI in a known relative location (for instance, in the same folder or a parent folder) and use the path of that VI to get your final path. That VI can be called statically and the behavior should be the same in LV and in the EXE, as the paths of items included in the EXE are stored relatively.


___________________
Try to take over the world!
Message 4 of 7
(319 Views)

@tst wrote:

LV maintains the relative paths inside the EXE (with vi.lib stuff going in a 1abvi3w folder). The exact structure of an EXE is a bit more complicated, but you can see this behavior if you look at the build folder while the build is happening (although that might end up messing your build up).

 

The practical upshot of this is that if you want to include something in the EXE without loading it statically and then load it, you can simply place a VI in a known relative location (for instance, in the same folder or a parent folder) and use the path of that VI to get your final path. That VI can be called statically and the behavior should be the same in LV and in the EXE, as the paths of items included in the EXE are stored relatively.


This is meant as a plugin system, so no static VI refs.

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 5 of 7
(271 Views)
Solution
Accepted by topic author Yamaeda

@Yamaeda wrote:


This is meant as a plugin system, so no static VI refs.


If all of your plugins are included at build time inside the EXE, you can still do this. The static VI doesn't have to be a part of any specific plugin, just something used to find the path for the plugins. 

 

If you want to then have a list of the plugins, I can think of two options:

  1. List folder. I'm not sure if this will work inside the EXE.
  2. Have a pre-build VI which takes the list of plugins (for instance, by reading the always included items list* or building it some other way) and then set that list as the default value in an indicator connected to the connector pane in a VI and save that VI and call it in the build to get the list.

 

 

* I haven't checked how to do this. It might be a tag in the build spec or it might require using the AB API VIs, which you probably can't. I suppose you could also extract it from the LVPROJ XML data.


___________________
Try to take over the world!
0 Kudos
Message 6 of 7
(249 Views)

@tst wrote:

@Yamaeda wrote:


This is meant as a plugin system, so no static VI refs.


If all of your plugins are included at build time inside the EXE, you can still do this. The static VI doesn't have to be a part of any specific plugin, just something used to find the path for the plugins. 

 

If you want to then have a list of the plugins, I can think of two options:

  1. List folder. I'm not sure if this will work inside the EXE.
  2. Have a pre-build VI which takes the list of plugins (for instance, by reading the always included items list* or building it some other way) and then set that list as the default value in an indicator connected to the connector pane in a VI and save that VI and call it in the build to get the list.

 

 

* I haven't checked how to do this. It might be a tag in the build spec or it might require using the AB API VIs, which you probably can't. I suppose you could also extract it from the LVPROJ XML data.


#1 doesn't work

#2 is what my collegue does now, i hoped there'd be a niftier way. 🙂

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 7 of 7
(145 Views)