Opening a VI Reference from an Application

[Bmarsh]

I have a VI that calls "Open VI Reference".

When I'm developing, its not a problem to generate the path, I just point at the path where the VI is located.

When I build an application, what the heck is the path to the VI?

[Bmarsh]

Actually, I'm getting error 7, and I don't think it is because the path is wrong. It is because the VI in question is called dynamically, and I guess that means I have to add it manually when I build the application.

The VI in question is part of a .llb, and other files in the .llb are automatically included. Is there anyway to force the app-builder to automatically include the entire .llb?

Going through and manually selecting all the dynamically loaded VIs is painful. If I add the .llb as a support file, I'm afraid that the non-dynamically loaded stuff might get put in twice and cause a conflict.

Anyone got a good way to do this that doesn't involve manually selecting the dynamic files...

[Labviewguru]

When I build applications (except dlls) I always use a loader. This way, ALL VIs are dynamically loaded (at once).

There is a discussion about this elsewhere if you were to search through my answers or other questions about this subject. Sorry I don't have time to fully answer it right now.

[Labviewguru]

Gee brad, why are you using LabVIEW. Wouldn't this be easier in C++?

No really, the path to VI in LabVIEW becomes the path to the executable. This is the same with dlls (there's that large project built as a dll in LabVIEW and much quicker and easier than with C++ thing again...). So, you cannot specificy "This VI's path" as a relative source.

When developing built applications, you have to consider the deployment. I came up with a utility that points to a file (in this case, an ini file) based on whether the application was in development (one location) or deployed (another location). You then have to know to move the file (or have a copy) from one to the other directory as appropriate.

[JeanPierre]

.
LabVIEW can't figure magicallly which VIs you'll call dynamically to include them in the application. That is why you have to add them yourself as "Dynamic VI" in the application builder. It is a one time procedure and may be tedious at most but not painful...
When you add a VI as Dynamic VI in the AB, the VI and its subVIs are included in the application internal LLB so you do not have to specify the subVIs in the list.
Labviewguru suggested to include the dynamic VIs on the diagram of a loader VI (set as Dynamic VI in the AB). It is true that all subVIs will be automatically included but you will find the procedure as tedious as selecting them in the AB.
About the Dynamic VI path in a built application, the good news is that you don't have to care
at all. When opening a VI reference from a VI path, the server first looks in the application internal LLB (where are stored dynamic VIs) to search for a VI having the same name. If one is found, the actual path is ignored and the internal VI is opened. Thus you can leave the same path you used in LabVIEW development to build an application calling Dynamic VIs.
Including a LLB as support file won't have any effect on the application. The LLB will simply be copied as is in the destination directory so unless you build dynamic VI paths to this exact location, the VIs won't be found.
Error 7 means that the VI specified in the path was not found neither in memory, in the internal LLB nor at the actual path. Unless I'm mistaken it also occurs when you attempt to open the front panel of a VI which FP hasn't been saved. By default the AB do not save the FP of dynamic VIs, you have to change this setting manually when required.

[Bmarsh]

Yes, the problem was the VI wasn't in the application, the path was fine.

To me something that is needlessly tedious is painful. A really great enhancement to the AB would be to be able to include an entire LLB. My present issue is that I have many LLBs that represent GOOP objects. Some of the methods are called dynamically to simulate polymorphic inherited behavior. It would be nice if I could say "include this entire library in my application", whether I call all the VIs directly or not.

I think the solution for me is going to be using the AB to build the application, and distribute it (its only internal anyway) with the LLBs in a specific location that the application can load from.

Thanks for the help.