Reentrant References In an EXE

[hooovahh]

I had a big long explanation typed up and accidentally it the back button. I don't fee like re-typing the whole thing so here's the shorter version.

I have a reentrant VI that is launched multiple times. In development you can open a reference to the VI by full path, but in an EXE the path is unknown. So you open the VI reference by name, but for this to work the VI needs to be in memory. So attached is one technique I've seen to keep a VI in memory by putting it in a case that will never be executed. Just run the Main.vi click Make New Graph Window and stop when you are done. This code will work when built into an EXE because nothing is opened by path.

Is this the right way, or are there other ways to force the compiler to add a VI as a dependency, so that a new reference can be opened by name?

Reentrant Reference Test.zip

[Yair]

The easiest and safest way is to use a static VI reference - you drop it from the app control palette and then drag your VI into it. You can then use the name or path property from that. It will work correctly both in LV and the EXE and will also force the VI into the build.

P.S. In the image the reference is connected to the type input because I often configure it to be strictly typed and then you can use it with the ACBR node.

Edited September 10, 2012 by Yair

[hooovahh]

Thanks, not sure why I didn't think of that.

[JackDunaway]

And don't forget the idea by jcase on the LV IdEx that could get rid of 75% of this syntax!

[GregR]

Just to clarify for others that stumble across this discussion. You can open references to VIs built inside an EXE by path but this is only possible from VIs running as part of that EXE and the path will be different than during development. That path difference makes this error prone and a bad idea, but it is possible. In general the VI path is the EXE path with the VI filename added as another path segment at the end. However this has problems with class/library files that have the same filename. How LabVIEW resolves these conflicts also depends on the Advanced build setting for "Use LabVIEW 8.x file layout". If this option is on, then LabVIEW will put the files in directories next to the EXE. If the option is off, then LabVIEW creates virtual directory structure under the EXE. I won't try to fully explain this, but I will say that is repeatable between builds so you can figure out where the VI is being put and reference it from there.

Most of the time there is a better approach but this is an option if you can't find another answer.

[Cat]

Just to clarify for others that stumble across this discussion. You can open references to VIs built inside an EXE by path but this is only possible from VIs running as part of that EXE and the path will be different than during development. That path difference makes this error prone and a bad idea, but it is possible.

This is the way I generally deal with multiple dynamic reentrant vi calls. I put the caller vi and the reentrant VI in the same directory level. Works with both source and EXE (with the caveats GregR mentions, I suppose).

The benefit to this is I can reuse my calling program by just having the vi name (no path) as an input -- and inputs for "Control Value" and "Value" (flattened) of "Ctrl Val Set", if necessary. Very flexible.

The only drawback I can think of is having to remember to include the vi in the build.

[Yair]

This is the way I generally deal with multiple dynamic reentrant vi calls.

Then I would highly recommend switching to the method I showed above. Unless you explicitly don't want the subVI to be loaded in advance, it's better in almost every respect (it includes the VI in the EXE, it gives you the connector pane, it removes reliance naming).