how do i disable a stop button within an event

[JoeSz]

Using LabView 8.6 I'd like to disable my vi's stop button so the user can't stop the vi unless the network application is in the correct mode of operation.

I only want the user to be able to stop the vi when it is ok to do so. What I tried works to prevent the stop button from operating at the wrong time but the vi does not always stop and I have to force the vi to stop.

My event structure handles all the buttons and inputs for my vi. The event structure is within the while loop that generates commands for the network application when I click on one of the buttons or enter a value into a input field. Another while loop is reading data from the network application and displaying the data on the vi. I used a "Stop" local value to stop the display while loop.

How am I supposed to disable the stop button but have my vi stop when it is ok to do so in the correct way?

[altenbach]

if the state is wrong, wire a FALSE out of the inner case structure instead of the state of stop button.

(it always helps to attach actual code, we cannot really tell much from a picture)

[0utlaw]

I'd recommend using a filter event to reject the value change if the state is inappropriate- it's probably your only option as you're using that local variable in the display loop.

Also, remember that your application should let the user know *why* what they just attempted to do failed- there's nothing worse than an unresponsive UI that refuses to close (well, that's an exaggeration- there are worse things).

Regards,

[JoeSz]

I've attached a vi showing what I'm trying to do without adding everything (that wouldn't work without the network application anyway). While the uploaded vi works correctly, I still have the quit problem with my complete vi. I've tried using the "NewVal" in my stop event along with a "MODE=0" test as an ANDed input to a true/false case that outputs "true" when it's ok to stop and "false" when it's not. In the "false" case I reset the "stop" button to the "off" state.

I've tried to supply appropriate comments of what my complete vi would be doing but I've omitted from what I've uploaded.

I'm beginning to wonder if the network connections are the problem. I've added some debugging LEDs to both my vi and the one I've uploaded. I added a "Stopped" LED to my command while loop and a "Data" LED to my data loop. I was thinking maybe one loop had stopped but for some reason the other was hung-up. Both LEDs indicate both while loops have stopped.

Any more suggestions would be welcome.

Thanks, Joe

[camerond]

Why not just make a "Disabled" property node for the Stop button which switches to "Enabled" when Mode = 0 and "Disabled and Grayed" when Mode = anything else (using a case structure)? Then you still can use the common "Latch when released" mechanical action of the button. You could use a "Value (Signaling)" event to check on the Mode status and set the button property then poll for the stop button action, instead of the other way around.

Cameron

[JÞB]

First that whole case structure needs to go bye bye or feel free to post it over on breakpoint in the Rube Goldberg thread.  It outputs True in the True case and False in the False case.  Just set the Mechanical Action on "STOP" back to Latch when released and wire the AND output to the conditional terminal.  Delete the other "Stop" Local too,

Next place the "Stopped indicator outside the event handleing loop so that it is written to true only after the loop completes- that really improves only the readability of the code but does make it obvious that the ACQ loop completion is dependant on the event loop.  When you put all the rest of the code back you'll thank me for that.

then get a case in the Event Structure to handle the application close? Filter event and discard the app close event.  Someone hitting the Windows Red X will leave you in a bad state unless you do that (See also final point)

Now your FP values will always be as expected UNLESS someone hits the abort button- then all bets are off and the system can start in an unexpected state causing unexpected results.  SO DON'T DO THAT anymore.  Rip off the abort button- It is a debug toy only and can really cause trouble and hair-loss, as you are finding out.

Final Point:  Are you really sure you want to disable a stop button?  (I think I've shown that ignoring Stop's output and depending on your other condition as determined in a stop value change event is preferable but I am making a point here)  Users expect applications to behave in "Normal" ways.  "Stop means Stop!"  and "Stop is always a valid thing to do".  You are almost always better off performing a graceful exit that releases all resources and cleans up after itself.

So a proper QSM design pattern implementation will improve performance and make maintanence a whloe lot easier when the Stop event enqueues (opposite end) a Exit command where Exit places everything in a nice clean state.

@Cameron-  I'm sure you would have followed the "Use a latching Stop" idea to its eventual simpler "and output the AND result" had the RG Case structure not obfuscated the code nearly beyond reading.  Allways be wary of boolean case structures- many sins are hidden in them.  If a select can substitute for the case, use select and there is no hidden code.

[JoeSz]

camerond,thank you, the suggestion for using a "Disabled" property node worked to disable the "Stop" button (once I figured out it needed to be in the "data loop" rather than the command loop).

Jeff·Þ·Bohrer, what gets wired to the "SilentShutdown" & "Discard?" when using "Application Instance Close?" I've tried various combinations of nothing & true/false but clicking on the "Windows Red X" still closes the window (as far as I know no one has ever clicked the windows close, but the "Stop" button has been clicked a number of times by mistake). If I get the previous suggestion to work and follow the next suggestion (Rip off the abort button), I won't be able to ever stop the vi when it hangs. It still does that sometimes. In my actual vi I'm still getting the hangs. The "data" and "command" loop LEDs are lit (indicating the loop has stopped?) but the "Waiting" LED does not come on. Yes I'm absolutely sure I want to disable the "Stop" button because if the vi stops the network communication & control to the network application is lost then the only way to stop this applications is with "^C" in the Putty window.

My real vi "data" loop contains a "Scan From String" (reads 66 values) which is being supplied by a "TCP Read". The "error out" is being examined using an "Unbundle By Name" to examine the "status". The network status is always "true" (I have a LED for that). I can't use "Highlight Execution" because it slows the my vi down so much the vi doesn't work at all (the slowest update rate is 1Hz). Is there a way to find out where the vi is  when is hung up? Will "Retain Wire Values" help? Should I use a "Flat" or "Stacked" sequence to control the order of execution within the "data" loop? Will I be able to pass the output of the "Stop" button the the while loop's "Loop condition" in the first frame to prevent the "TCP Read" for execution in the next frame?

[JÞB]

OK I'll try to handle this point by point.

Q1, what gets wired to the "SilentShutdown" & "Discard?" when using "Application Instance Close?" 

A1 Wire a TRUE to Discard?  That's the only thing that event case needs if the Stop condition output is default if unwired "F"   

REASON you had a problem" it makes not sense to wire the same value to both Discard? and Silent Shutdown?  (Or even use both)  Discard in Filter events is used to "Trap" the event and decide if the app really wants to process it so discarding an app close removes the event and the OS wont process it.  Silient Shutdown? does just about the opposite an tru hear means "Shut down the app without any normal user prompts" Wiring them both T or F would trigger either allowing the app close event to process normally or triggering a application shutdown.

COMMENT:  I've tried various combinations of nothing & true/false but clicking on the "Windows Red X" still closes the window (as far as I know no one has ever clicked the windows close, but the "Stop" button has been clicked a number of times by mistake)

RESPONSE: Ah! You have "Trained" LabVIEW users!  They have been burned so often by LabVIEW code that they expect it to misbehave and don't even think about trying to "Close" a LabVIEW window.  In decades past the event structure did not exist in LabVIEW and so the only way to prevent the app close event from firing was "User Training."  There are better practices available now.

Q2: If I get the previous suggestion to work and follow the next suggestion (Rip off the abort button), I won't be able to ever stop the vi when it hangs. It still does that sometimes. In my actual vi I'm still getting the hangs.

Amplifications:

• if the vi stops[,] the network communication & control to the network application is lost.
• then the only way to stop this applications[external app on another processor] is with "^C" in the Putty window.

A2: You've got the tail wagging the cart before the dog-horse!  BOTH application need to be rethought in such a manner as they can be independantly controlled.  But, this is a LabVIEW forum so I expect that your scope of work is to get the LabVIEW side working in a dignified manner- let's concentrate on that.  PuTTY windows and Task Managers are not evil - for debugging and integration.  especially when integrating multiple processes that may not yet be "Mature".  but a quick VISA write "^C" in your shutdown code might make the other application tolerable

Q3:Should I use a "Flat" or "Stacked" sequence to control the order of execution within the "data" loop?

A3: NEITHER.  You should do a quick forum search for Queued State Machine or Queued Message Handler (QSM and QMH) after looking at the help for the QSM Sample Project (LabVIEW 2012 or later) the Shipping examples are a good place to start but! many discussion threads have questioned the example's exit practice and offered some alternate examples.

[JoeSz]

I have LabView 8.6 (2008) so your suggestion for using "Queued State Machine or Queued Message Handler (QSM and QMH) after looking at the help for the QSM Sample Project (LabVIEW 2012 or later)" is not going to happen.

LabView generates the shutdown command (correctly) and transmits that command to the network control application (correctly) which acts on it (correctly) and LabView is displaying data (correctly). The only issue I'm having is with is LabView shutdown down after everything else has shutdown.

I'll settle for the LabView GUI shutting down properly "most of the time" and use the "Abort" button for those cases when it doesn't. There aren't any problems with this. I just thought I'd get a simple suggestion on how to fix this (what I thought was a simple) problem. My primary objective is to develop the other tools not a LabView GUI.

[Myr.i.am.]

Hey JoeSz,

Although LabVIEW 8.6 doesn't have that Queued State Machine example, it still includes the necessary functions to build one.  I've linked to a community post with more details.

https://decibel.ni.com/content/docs/DOC-32964

Myriam

Applications Engineer

National Instruments