Stop Primitive

[zenthoef]

So you know that stop primitive? The one that looks like this:

Is there anything to be concerned about when using this? I know it operates like the Stop button next to the Run Arrow. What I've been told about that stop button is that, "Stopping your code with the stop button is like stopping your car by running it into a tree." That doesn't sound like a very good idea, in general!

In most of our exe builds at my work we have an "Exit" button that makes the state machine go to an Exit state that shuts the test equipment down (DAQs, serial ports, GPIB, etc..) and then stops the state machine code. However, this makes it so that the program appears to stay on the screen, but it is not running. The only difference is you get the little run arrow at the top that most manufacturing technicians do not notice. Then the think the program is frozen when it is really just not running.

To solve this problem it has been proposed to use the Stop Primitive in the Exit state after all communication ports have been disconnected. Is it a good idea to acheive this desired effect with the stop primitive? Is there anything to be careful with it? Are there other methods to close the window after the program has stopped?

Thanks in advance! 

[RavensFan]

What you might want to use is the Exit LabVIEW primitive.  If your code is built into an executable, then it closes out the executable.  Unfortunately if you are developing in your LabVIEW development environment, it can be kind of annoying to have all of LabVIEW close when you just want to stop your code to make some modifications.  You can use the App.Kind property to determine whether you are in the Runtime environment or Development environment and make the decision to Stop LabVIEW once all cleanup code is done or to actually Exit LabVIEW.

[RTSLVU]

Like Ravens Fan said I use this little vi all the time.

It automagically stops or exits depending on what "mode" the vi is running in.

Stop if running vi in development system

Exit if running exe in runtime system

[altenbach]

I don't understand why you need to stop primitive in the cases that don't have the exit primitive. It is typically better to let the code finish naturally, at which point it will stop automatically.

The stop primitive is somewhat dangerous, because some modules could still be running shutdown code, write the final log to file, etc.. The stop primitive is only needed for poorly written applications that don't communicate the program termination properly to all parallel running parts. You should never need it.

[Ray.R]

I agree with Altenbach.

To add to his concerns:

What if a later section of code does the house cleaning  / garbage collection (or in good old LabVIEW jargon:  close references, etc).

But the code does not make it to that section due to the STOP primitive?  It may result in memory leaks...  bad.

Now, if this is part of the development code where you want to stop the application in order to trap a bug, then it is a different story.  Not a good one, but by necessity, you use it..  That is quite different from leaving it into an application..

Go in clean... come out clean...  That's the way to program 🙂

[zenthoef]

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! 

[F._Schubert]

You might want to read through this of Darren's nuggets.

Felix

[RTSLVU]

---

@altenbach wrote:

I don't understand why you need to stop primitive in the cases that don't have the exit primitive. It is typically better to let the code finish naturally, at which point it will stop automatically.

The stop primitive is somewhat dangerous, because some modules could still be running shutdown code, write the final log to file, etc.. The stop primitive is only needed for poorly written applications that don't communicate the program termination properly to all parallel running parts. You should never need it.

---

It just seemed "unfinished" without the Stop in the other cases.

Since I just tack this vi onto the end of any program that is going to be compiled and deployed usually right before I compile it, I have never had any issues with it.

99% of the time I am running from the development environment anyway and just let the code finish natrually.

[SteveChandler]

---

@zenthoef wrote:

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 put it in every executable and I would say it is extremely common. It was already pointed out that you need to check if you are in the runtime or development environment

This code is either directly or indirectly in the Panel Close? event with Discard? Set to true.

[altenbach]

---

@SteveChandler wrote:

I put it in every executable and I would say it is extremely common. It was already pointed out that you need to check if you are in the runtime or development environment

---

There is even an idea that suggest that these this would be default behavior for executables without need of any fancy code.

Add an easily accessible way to close an application

Everybody reading this, make sure to support it if you agree! 😄