04-20-2011 11:50 AM - edited 04-20-2011 11:53 AM
@zenthoef wrote:
Maybe I wasn't clear, but I was just asking about using the Stop primitive in the Exit case only, not about putting it in all cases. In our Exit case that is where we close DAQ tasks, serial ports, etc... I think Ravens Fan may have nailed it by suggesting we use the Quit LabVIEW primitive instead of the Stop primitive. How common is it for people to use the Quit LabVIEW primitive to fully close an EXE when the Exit case executes? If it is a fairly common practice maybe I'll start doing this to completely shut down my programs.
I knew the Stop primitive probably wasn't a very good thing to use in this instance, but wasn't sure how to pursuade others to see that. Offering the alternative of the Quit LabVIEW primitive is probably the way to go as long as it is safe!
My bad...
When reading your original post, I saw the Stop primitive and your comparison to the abort execution button. I though you wanted it to stop the program anywhere, like many people do, anywhere in the execution.
I have no issues with the Quit LabVIEW primitive when used in the exit case, or at the end (after the loop) of the program. I actually use it, although I need to put a App.Kind to avoid the block diagram from closing when developing code. You can also wrap it inside a Conditional Disable Structure (later versions of LV) with appropriate selection for RUN_TIME_ENGINE as described here.
04-20-2011 12:48 PM
@Ray.R wrote:
My bad...
When reading your original post, I saw the Stop primitive and your comparison to the abort execution button. I though you wanted it to stop the program anywhere, like many people do, anywhere in the execution.
I have no issues with the Quit LabVIEW primitive when used in the exit case, or at the end (after the loop) of the program. I actually use it, although I need to put a App.Kind to avoid the block diagram from closing when developing code. You can also wrap it inside a Conditional Disable Structure (later versions of LV) with appropriate selection for RUN_TIME_ENGINE as described here.
That's ok! I think things got confused because, I think, Altenbach was refering to RTSLVU's vi he posted. I was confused at first thinking Altenbach was replying to my post, but I think he was replaying to RTSLVU's, and not my original post.
That aside, I hadn't thought outside of the box (rather, loop) and I will probably end up putting this after the loop of the program. That seems like a more appropriate place.
04-20-2011 01:43 PM
@zenthoef wrote:
I hadn't thought outside of the box (rather, loop) and I will probably end up putting this after the loop of the program. That seems like a more appropriate place.
LOL!! Yes, indeed. That way you do not need to worry about anything preceeding it (ie: garbage collection, etc)
🙂