I'm trying to figure out how I could make custom libraries that my exe would load dynamically, and those external libraries could use as subVIs some VIs that are "included" in Main.exe
I made this simple diagram to show how I see it, perhaps someone already faced that issue and found some workaround technique to make it possible.
The idea is to keep Main.exe as standard as possible, without having to make a new build each time we make slight new features in custom.vi
Solved! Go to Solution.
You can simply call the sub.vi in your custom.vi and load the custom.vi dynamically. I don't understand what is the issue here. Are you facing any problem calling the dynamic VI (custom.vi)?
Yep, when you load the VI I think it will first look in memory for any dependencies, then look in the paths stored in the file (ie ../blah.vi for a VI in the same folder) and then finally look at the LabVIEW search paths (vi.lib in the dev environment, I don't think there are any extra search paths in the runtime env). Just use VI server to load it and everything should be OK.
If you are concerned about making this deployable, you can build the "custom" vis into an LLB (source distribution) and exclude the VIs you expect to load in your main VI. You can also build your custom stuff into a packed project library (basically a dll), but you can run into dependency issues pretty easily there (source).
And of course if you want to take it a step further, you can implement your exe using an interface class and load up an instance of "custom.vi" as a class using something like the factory pattern: https://decibel.ni.com/content/docs/DOC-13724
my concern is only about the sub.vi that is no longer on the hard drive which results into a broken custom.vi
Main.exe contains sub.vi but also calls dynamically the actual custom.vi from a separated library on the hard-drive. custom.vi still looks for sub.vi but I'm just trying to figure how to reference it to main.exe available VIs in run-time.
Sorry seems I'm getting mixed up these days!
Can you build an installer?
This is not all that difficult, just your requirements aren't perfectly clear.
For this to work well you'll want your Main.VI to open a reference to the custom.vi by using the path to the VI on disk. When I do this type of thing I try to use a recursive file list, and use the paths to the file, knowing that it exsits. Obviously if you try to open a reference to the VI not there it will generate an error.
Then using that reference you can use the Call By Reference node, calling the VI dynamically with normal inputs and outputs. For this to work you'll need the connector pane of the dynamcially loaded custom.vi to be known. Again if the connector pane of the custom.vi doesn't match the connector pane of the Call By Reference node an error will be generated.
thanks for your answer, my problem is not to dynamically load a VI.
The thing I need to know is: custom.vi uses sub.vi which is inside Main.exe, how can we get it work?
AHHH, okay well you can go in the reverse, where custom.vi also loads the subVI dynamically but it does so using the VI Name not the path. The Open VI Reference accepts the full VI name not just the path. So if you provide the name of a VI to use, and that VI is already in memory (which it will be because it is loaded from the main.vi) then it uses that.
That's one option. You can also get the path to the subVI in the EXE like C:\my application\program.exe\subVI I want.vi but the location of the VI in the EXE isn't flat starting in 2009 by default so the path in the EXE may not be known.
You don't need to worry about it. As was already stated, the version of the subVI that is currently in memory will be used. If you don't believe me, give this a try.
I have a VI that calls subVI and another VI that is called dynamically that also calls the subVI. The subVI just keeps track of how many times it was called.
That's cool if the VI is referenced somewhere in main.vi but if I modify your example by removing the direct call of sub.vi, it's not working anymore, even if I put it in "always included" list.