> > Honestly, is this code scary?: > > <http://lavausergroup.org/labviewimages/dynamicrun.gif> :-) That's > > really all you need. > > Well, you conveniently forget that you usually need to have > some means of communicating with this task through queues or > in my case more often functional globals. Not much to do > about that and no matter how you do it dynamic or not this > remains the same, so it is not a drawback of your method but > one of using parallel tasks in general, but the benefits can > make the difference between a user friendly, safe and easy to > use application or a thing not even the programmer himself > can use after a few months.
Well, to create a non-blocking VI, the above code snippet is really all you need. Communication wouldn't be required if your goal is just that. > The only issue I have with dynamic VIs is that I have managed > to get them into a state where they were remaining running in > the background while anything in LabVIEW was gone. The only > way to get out of this if you don't know which VI blocks and > which functional global or whatever you need to load and > tickle to abort that task, is to ctrl-alt-del. > Rolf Kalbermatter Another way to track them down would be to Browse>>Show VI Hierarchy. This will list any dynamic VI's in memory. You can pop them open from there. One way to avoid getting Dynamic VI's in this state is to set the "Auto Dispose Ref" input to False. This will maintain a reference link from the caller to the dynamic VI. What this means is that you can terminate the dynamic VI from the caller just by doing a "close reference" function on the reference. The other side benefit is that if for any reason the caller terminates (normal stop or ABORT) then the reference is automatically closed by LV which will in-turn terminate the dynamic VI. For all this to work you must not allow the dynamic VI to open a reference to itself. Michael Aivaliotis
