Dynamically loaded VI using a subVI included in the .exe

[dems]

Thats because "subvi" is included but not in memory. Since it isn't in memory, "custom" looks for it on disk where it previously loaded from and can't find it. If you replace the direct subVI call with a static VI reference to "subVI" it should still work. If you set "subVI" to "always included" and then have the main dynamically load "subVI" before loading "custom", it will work.

Remember the key concept is that you have to do one of two things:
(1) Ensure "subVI" is in memory before "custom" is loaded

(2) Ensure that the links "custom" has to other code are all preserved when moving between dev and runtime environments

(1) is a ton easier in a lot of cases. Even if you don't want to statically include them, you can theoretically have a giant folder full of dependencies and just tell "main" to load all of them before loading "custom" and it will probably work. 

Another way of thinking about it is this: if "subVI" isn't loaded into memory by "main" then why do you want to package it with "main"? In that case, it should be packaged by "custom" because "custom" is the only thing in the system which uses it.

[JimChretz]

Thanks for your reply, that helps.

The subvi is supposed to be loaded by main.exe at some point but I'm just afraid that it might happen that custom.vi loads a vi before main.exe.

subvi simplifies a quite big amount of different VIs.

But now I understand better, I can make some tests and make sure the subVIs will be loaded in memory before custom.vi enters the game.

[Hooovahh]

There are other ways to force the VI to be in memory in the Main without having to call it.  You can have a Static VI Reference to it on the BD somewhere.  Or another one I've seen is in a state machine have a case that is never called, and drop down all the subVIs you want to always be included in there.  The compiler can't know that case will never be called, so it can't use constant folding to remove the case, and the call to the VIs.  If you just have a case structure with a constant of false wired to it, and all of your VIs in the true case, then the compiler gets too smart for itself, and will remove the true case, and will remove the calls to those VIs that you wanted in memory.

[JimChretz]

I think a good efficient way to handle that situation would be to catch the error code related to the VI not yet in memory, and to have a special case for that error handling that loads the static VI, the VI filename could be passed to the state case and launched there... I'll think more about it.

Loading hundreds of VIs might slowdown the software startup.

[Hooovahh]

---

@Jimmy.chretien wrote:

Loading hundreds of VIs might slowdown the software startup.

---

Oh that's a whole nother discussion with dynamically loading VIs for a splash screen.