Dynamically Load VI Into Application With Dependencies

[SteveChandler]

Maybe there is a very good technical reason why this idea is not a good one.

Problem: If I want to load a vi into my application the subvi's of the dynamically loaded vi can not be found.

My Plug-In Application (EXE) is Not Calling My Plug-Ins Correctly

Solution: Add a boolean input (or an options flag) to Open VI Reference which will load the vi and modify the search path so the subvis can be found.

I know there are several workarounds but I would like this to be easier.

[AristosQueue (NI)]

If you set the boolean to true, what would you modify the search path to be? The LV runtime engine would have to be told somehow where the subVI files are located. There's no way for it to "just know."

[SteveChandler]

If I open a vi in LabVIEW it just knows where the subVI files are. That's what I don't get - why does that information get lost when I open the same vi dynamically.

[AristosQueue (NI)]

When a VI saves, it records paths to its subVIs. For most VIs, the VI records a relative path. So if the caller VI is saved at c:\X\caller.vi, and the subVI is saved at c:\Z\sub.vi, then the caller will record the path "..\Z\sub.vi". For VIs that are saved in vi.lib or user.lib, the path that gets saved is

<vilib>\dir\sub.vi

or

<userlib>\dir\sub.vi

The reason these are saved special is because if you load the same VI in a different verison of LabVIEW or on a different platform, you need the copy of the subIV that is specific to that version of LabVIEW or that platform.

I suspect it is these directories that are giving you fits. When a VI is loaded into a built app, it can always find the subVIs that are recorded with relative paths. For those with pseudopaths, there's no way to know where vi.lib or user.lib is located -- the runtime engine doesn't have its own copy of these. That's why you have to create a source distribution version that creates local copies of these subVIs to distribute with the plug-in VI, so that there is a relative path copy of the VIs in vi.lib and user.lib for the runtime engine to load.

[SteveChandler]

Thanks Aristos for another clear explanation of a complex topic!

[AristosQueue (NI)]

So... back to your idea... would you want another input on Open VI Reference that is some sort of way to specify a location for the pseudopaths?

[SteveChandler]

I got the impression that the idea was dead

What you are saying is in the spirit of the idea.

I have an application that loads plugin modules into a subpanel at runtime. These plugins are source distributions saved in llbs. It works pretty well but all of these llbs have their own copies of vis for getting messages from and sending replies back to the main application. It just seems inelegant to have multiple copies of a vi in several places but after your explanation above I think there is a better way to do this.

It seems the right way to address the problem I want to solve is "method 4" in the KB - specify the search path in the exe.ini. It is the only one that does not result in having multiple copies of vis everywhere.

But that is modifying the search path for the executable and anything that gets loaded. Since there is no such thing as a vi.ini then specifying the search path for just that vi at load time could be an alternative. Unless there are reasons that a "context" (I think that is what you call it) needs to have only one search path.

If you can not think of a good reason for a feature like this then I wouldn't even dream of arguing for it. I think it would be cool if LabVIEW could tie my shoes but there are some things that are rightly the responsibility of the developer. If this idea is one of those then I have no problem letting it die. Besides there is not a single kudo

[AristosQueue (NI)]

I don't think it is necessarily dead, but the idea may need to mutate.

-----------------

Unfortunately, you're running into the LV equivalent of DLL Hell.

Plugin systems -- such as a VI plugin for an EXE or a repository of shared DLLs -- are inherently a mess. You are trying to create a decentralized way for new code to be plugged in but in a way that requires a centralized repository of information for every plugin to know what every other plugin is doing.

Any plugin system must be constrained by some rules that are logically impossible to avoid. Options include:

A) A plugin includes all of the binary code that the plugin needs to execute, and namespaces that code to prevent collisions

B) A plugin uses VIs included with the framework system

C) A plugin has an installer that chooses what files to install so that multiple plugins can share common code

D) You actually create that centralized authority that approves plugins and makes sure they're compatible with each other

Imagine the problem that would arise if user A builds a plugin that uses X.vi from version 1.0 of a toolkit and user B builds a different plugin that uses X.vi from version 2.0 of a toolkit. When both plugins are installed on a machine, either you have some way for both versions of the VI to be in memory at the same time (meaning you did some sort of namespacing for the VIs) or only one copy wins. If every plugin does its own namespacing, then you have a problem when two VIs use the same version -- they will each have their own namespacing, and so the code isn't shared. If only one copy wins, you hope that it is the 2.0 copy and that the 2.0 copy is backward compatible.

The VIs in vi.lib and user.lib are -- to some limited degree -- already broken out so that the sharing strategies can be easily applied, but if two plugins share your own user VIs, you have the "too many copies" problem.

So, that should give you something to think about. Look at your own systems and see if you can come up with something that we could add to LabVIEW that would help you to specify the location of these shared code pieces. If you find something, post it here and let the community kick the tires a bit.

[SteveChandler]

Thanks again.

I was playing around with specifying the viSearchPath in the exe.ini. It doesn't seem to work with relative paths. Either I have a stupid invisible typo or the path can not be represented as a relative path.

If it is the latter then maybe the idea will evolve to specify relative search paths in viSearchPath.

[Darren]

Any idea that has not received any kudos within a year after posting will be automatically declined.