Jump to content

Reentrant References In an EXE


Recommended Posts

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

Link to comment

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.

  • Like 1
Link to comment
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.

Link to comment

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).

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.