Launching a Dynamic VI Staticly

[Ryan Podsim]

I'll start with my intent. I would like to be able to launch a VI dynamically using some sort of explicit reference. I have included the Project and VI's I created in trying. I used a simple setup of trying to launch a VI that displayed a one button dialog.

At first I thought "Use a Strict VI reference". That didn't work. (see Launch reference.vi) You can't explicitly link a VI to a Strict VI reference. OK - not perfect but surely there is a way.

Seconded I thought "Lets have the VI I want to call give me it's path and launch it by opening a reference". That didn't work either. (see Launch non rentrant.vi) I get an error stating that "The VI is not in a state compatible with this operation." This is the point I don't get. I can call the VI directly (see Launch direct.vi) Why can't I launch it through the VI server? I know its not actively running but the execution state is "Running" and I can neither Run or Abort the VI since its calling VI is running.

I can launch the VI if it is set as rentrant. (see Launch rentrant.vi)

The point of this exercise was to avoid the problems with path relations and app build issues with dynamic VI's not being included. I have a series of VI's that I would like to launch dynamically (eg. a calculator that can be launched via a menu option but not interfere with the main application). And no, creating a separate EXE for the dynamic VI's would not be acceptable. I will need to be able to deploy this is the run-time environment and possibly over multiple OS's.

Any Ideas, directions, or solutions would appreciated.

LAVAG Dynamic.zip

[Aristos Queue]

I can see the problems you're having, but I am slightly unclear on exactly what your goal is, so I'll lay out a couple of options and hope one of them helps.

You have some VIs that you want to invoke dynamically.

1) If you're trying to get those VIs to load into memory at the same time as your top-level VI, what you want is a "static VI reference". [Note: "static VI reference" and "strict VI reference" are not the same thing, and, yes, it is possible to have a "strict static VI reference".] It's in the Application palette. This creates a reference to a subVI but does not invoke the subVI. You can then use the reference that comes out of that node and wire it to either the Call By Reference node or the Run VI method. If you *know* that you're going to want to run these VIs as part of your app but you just need to choose among them dynamically as the app runs, you will find it is most efficient to make these static VI references be "strict" by popping up on them and choosing "Strictly Typed VI Reference". That causes the subVI to be reserved for run when the top level VI starts running, the same way all the usual subVIs get reserved. Not doing this means that the subVIs will be reserved before every run and unreserved when the run finishes. Being strict also means that you cannot use the "Run VI" method. Being strict means that the VIs are set up to run as subVIs of another app. The Run VI method executes a VI as a top-level VI.

2) The objection you might have to item #1 is that the subVIs will all load into memory. If you truly want to dynamically load these VIs into memory then you have to use Open VI Reference and supply a path. The easiest way is to put all of your dynamic subVIs in the same directory as the caller VI and then use "This VI's Path" node to get the path of the caller VI, then do "Strip Path" and "Build Path" to replace the file name of the caller VI with the file name of the desired dynamic subVI. From there you can again use Call By Reference or Run VI. Again, if you wire a conpane to the Open VI Reference node, the resulting reference is a strict VI reference which means you have to use Call By Reference to invoke it.

[MikaelH]

Hi

Since I have almost all my VIs in classes in my app, so when I want to dynamically run a VI (method), I use the Open VI ref using the string name instead of path:

"MyClass.lvclass:MyDynamicVI.vi" and as long as I use any VI on this class the whole class will be loaded in memory by LabVIEW and it works without me knowing the absolute path.

//Mikael

[Ryan Podsim]

Thanks AQ, I'm not sure how I missed the "Static VI Reference". That is what I need for most of the VIs.

Most of the VI's I want to launch are small sub-process or dialog type VI's to provide the user with inforation while the main app continues to function normally. In one case, I need to display a report/graph of the collected data the user can view, print, save... I had been calling the VI by path, but was having problems with the VI going missing(usually we forgot to "always include" the VI in the build spec) and figured there had to be a better/easier way.

MikealH, Will that work with libraries also or just classes?

[Aristos Queue]

MikealH, Will that work with libraries also or just classes?

Just classes. Libraries do not load all of their member VIs into memory just because the library loads into memory. Classes do.

[MikaelH]

So there you go guys, another reason to use classes in you applications :-)

[Aristos Queue]

So there you go guys, another reason to use classes in you applications :-)

Don't take that as a negative of LV Libraries. Libraries and classes serve different needs and so have different rules. :-)

[Daklu]

Just classes. Libraries do not load all of their member VIs into memory just because the library loads into memory. Classes do.

Err... when did this behavior change? 8.6 loads all library VIs and I thought 2009 does as well. Unless I'm not fully understanding what you mean by "load."

[Aristos Queue]

Err... when did this behavior change? 8.6 loads all library VIs and I thought 2009 does as well. Unless I'm not fully understanding what you mean by "load."

Libraries have never loaded their VIs in the entire time since they were introduced in LV 8.0. Classes always have since they were introduced in LV 8.2.

Open a .lvlib file. Yes, you'll see a list of VIs in the project tree but those VIs are not in memory, as you can see by looking at the VI Hierarchy window and choosing Show All VIs.

Open a .lvclass file. Again, you'll see a list of VIs in the project tree, but this time, when you look at the VI Hierarchy window, you'll see all those VIs are actually in memory.

[Ferrousduke]

Thanks AQ, I'm not sure how I missed the "Static VI Reference". That is what I need for most of the VIs.

Most of the VI's I want to launch are small sub-process or dialog type VI's to provide the user with inforation while the main app continues to function normally. In one case, I need to display a report/graph of the collected data the user can view, print, save... I had been calling the VI by path, but was having problems with the VI going missing(usually we forgot to "always include" the VI in the build spec) and figured there had to be a better/easier way.

MikealH, Will that work with libraries also or just classes?

Using Static VI reference will anyhow load that VI in memory behaving the same as calling the VI.

It makes nothing Dynamic..

[GregR]

Static VI references load statically but allow you to call dynamically. For many cases this is acceptable. If dynamic loading is important but you still don't want to deal with paths or VI names on your diagrams, there is actually one more option that delivers dynamic loading with static calling. On subVI calls there is a "Call Setup..." menu item. This allows you switch the call to "Reload for each call" or "Load and retain on first call". Either of these will avoid loading the VI initially, but still take care of managing the linkage to the subVI for you.

Keep in mind that any call to a subVI can cause it to be loaded, so if you want to take advantage of this, or any other dynamic loading scheme, you must be sure that all your references use dynamic loading.

The one case we can't manage the subVI linkage for dynamic load with dynamic calling. This still requires your diagram to compute the path to the subVI and it will not be known to the application builder or noticed at edit time if it is incorrect.