multiple instances of a subVI - problem if running as executable

[while_loop]

Now I have found the reason for that strange behavior: The dynamically generated VIs from the template
uses subVIs from an LLB located in an other directory. This directory is an subdirectry of 'instr.lib\...' and
if execute my program in the LabVIEW IDE all works find. But as executable the link to that directory seems
to be lost. My solution now is to copy the LLBs to the directory where the executable is located, is there
a better way to solve that problem?

Steffen

[billings11]

I have run into some very strange problems like this too.  I use vi references to call sub-vi's all the time.  I ran into this problem.  For example, a VI reference can't be passed around like a control reference from one vi to another.  Check my example.  The debug mode works fine, but the built application gives an error.  Why?  Now if I don't put the property node in a sub-vi it works fine, but as soon as put the property node in a sub-vi it will work normal in debug mode and will break in the application.  But why is it allowed in debug mode if it gets its own error code and everything in the executable?

Also check this out, and I can give an example of this one later too:  Say I have a top level vi that wants to open a sub-vi by reference.  Now to keep from having to deal with path information, I just put down the icon of the sub-vi on the diagram of the main vi in an unused case of a case loop.  So in other words, I am just putting it there to make sure it is included in the aplication build so I don't have to deal with linking it as a dynamic vi and worrying about it's path.  It is in a "False" case on a case that is hard-wired true all the time, so it isn't ever being executed directly.  Instead, I open a vi reference and with an invoke node choose the Run Vi method.  Now here is the wierd part.  Works 100% fine in the debug mode.  SHOULD work in the executable right?  See by doing this path information is out of the picture because it is linked within the executable and already loaded in memory, so I am just opening the reference by vi name.  Except it won't work in the compiled application - gives me an error.  UNLESS I make it reentrant.  Its like even though the vi is loaded in memory it won't run it unless it loads it in a duplicate spot in memory and is labeled reentrant.  If I make it reentrant it works beautifully - EXCEPT I can't use run-time menus in the sub-vi because they get disabled in all reentrant vi's.  So I have to write shell vi's around all of the vi's I want to call by reference and make THEM reentrant, then put all my non-reentrant real vi's called directly from inside my shell vi's to keep the run-time menus working.  Why have I gone through all of this?  Because the application builder is such a pain to work with and there are virtually no tools for keeping track of vi path information when you change things around.  Looks like this has been greatly improved in version 8, but I'll believe it when I see it.

[rmp]

So, I delving into the same type of application, and I think hitting yet another flavor of problem. Just to set the stage, my app:
 - is a realtime processing/display app
 - data is received continuosly by the top vi
 - the user requests a plot window from the top vi, and the top vi launches a template plotting vi
 - the user can request another plot window, and the top vi will launch the template plotting vi again, thus creating a new instance of the plotting vi
 - as an aside, I use the vi server to launch the plotting vi. But I also give the plotting vi a specific (unique) name ("plot window n", where n varies with each instance). And, I pass this name to the plotting vi so that I can reference itself to get the front panel size so that I can scale the graph by the size of the front panel (without scaling ALL controls on the front panel). Maybe this helps with the problems you're running into...

So, with that as the backdrop, here is the problem I'm having:
 - the multiple instances of the plotting vi are launching and acting fine, until I go to kill them...
 - I would prefer to just kill the window (instead of having a front panel button to stop/kill).
 - when I kill the window, I get a Labview pop up asking if I want to save the vi to disk. I suspect that this is because I changed the name of the template vi by forcing my own unique name to each instance.

Anyone have any ideas how I might gracefully avoid the pop up, and instead just kill the plotting vi window?
Also, (I don't have App Builder at the moment) I wonder what would happen if I were to build this into an exe?

Thanks, in advance...