Cannot stop VI

[johntrich1971]

---

@billko wrote:

---

@johntrich1971 wrote:

See if the attached does what you want. It's basically just a combination of what others have recommended.

Notice that there are no local variables, and I set the OK and Stop buttons to latch when pressed. 

For a simple program like this your current architecture is fine. For larger applications you may want to consider a more advanced architecture.

---

Is there a reason for "latch when pressed"?  Isn't is normally "latch when released"?  The reason being "latch when released" is how buttons normally work - i.e., no action until the button is released.  This subtlety can save you if you click on the button by accident - just hold the click, move the cursor off the button.

---

Hi Bill,

I don't have any particular reason to use "latch when pressed" other than in my experience with physical buttons they generally activate when pressed and it's the first latching action in the list, LOL. Also, the counter to your scenario of clicking on the button by accident is the user pressing and then sliding off before releasing when they're intending to be pressing the button. I think that it's generally a matter of preference that will rarely be noticed by the user.

[JÞB]

Latching booleans latch until they are read.  STOP Button is only read in the STOP Button value change event 

BUT, by the time the loop started waiting for an event the STOP Button Local Variable was read and returned a value of FALSE to the conditional terminal.  This is what we call a "Race Condition."

WORSE. In the OK Button value change event you depend on ANOTHER read of a STOP Button local variable to halt the inner While Loop  AND, the OK Button value change event locks the front panel until the event is complete so... you can't press STOP! This is what we call a "Deadlock."

Stop placing While Loops inside an Event case!  They simply don't belong there.  Never stop a loop from a local / global read of a latching Boolean. 

[billko]

---

@johntrich1971 wrote:

---

@billko wrote:

---

@johntrich1971 wrote:

See if the attached does what you want. It's basically just a combination of what others have recommended.

Notice that there are no local variables, and I set the OK and Stop buttons to latch when pressed. 

For a simple program like this your current architecture is fine. For larger applications you may want to consider a more advanced architecture.

---

Is there a reason for "latch when pressed"?  Isn't is normally "latch when released"?  The reason being "latch when released" is how buttons normally work - i.e., no action until the button is released.  This subtlety can save you if you click on the button by accident - just hold the click, move the cursor off the button.

---

Hi Bill,

I don't have any particular reason to use "latch when pressed" other than in my experience with physical buttons they generally activate when pressed and it's the first latching action in the list, LOL. Also, the counter to your scenario of clicking on the button by accident is the user pressing and then sliding off before releasing when they're intending to be pressing the button. I think that it's generally a matter of preference that will rarely be noticed by the user.

---

No.  It is definitely not usual behavior and you never notice it because you've never run into a button that behaves as "latch when pressed" - anywhere (except your applications).  Try any button on any application anywhere, and you will see "latched when released" behavior.  You can check by clicking and hold on any button.  No action will be taken until you let off the mouse button.  Now as to the actual reason why "latch when released" is the standard behavior for a generic button is beyond me, but if you want your apps to behave in a way constant with all other GUI apps (I believe a generic button behaves this way across all operating systems), that is the way you program a generic button.

I just thought of an exception.  Occasionally browser buttons are set to act in a "latch when pressed" mode.

[johntrich1971]

---

@billko wrote:

---

@johntrich1971 wrote:

---

@billko wrote:

---

@johntrich1971 wrote:

See if the attached does what you want. It's basically just a combination of what others have recommended.

Notice that there are no local variables, and I set the OK and Stop buttons to latch when pressed. 

For a simple program like this your current architecture is fine. For larger applications you may want to consider a more advanced architecture.

---

Is there a reason for "latch when pressed"?  Isn't is normally "latch when released"?  The reason being "latch when released" is how buttons normally work - i.e., no action until the button is released.  This subtlety can save you if you click on the button by accident - just hold the click, move the cursor off the button.

---

Hi Bill,

I don't have any particular reason to use "latch when pressed" other than in my experience with physical buttons they generally activate when pressed and it's the first latching action in the list, LOL. Also, the counter to your scenario of clicking on the button by accident is the user pressing and then sliding off before releasing when they're intending to be pressing the button. I think that it's generally a matter of preference that will rarely be noticed by the user.

---

No.  It is definitely not usual behavior and you never notice it because you've never run into a button that behaves as "latch when pressed" - anywhere (except your applications).  Try any button on any application anywhere, and you will see "latched when released" behavior.  You can check by clicking and hold on any button.  No action will be taken until you let off the mouse button.  Now as to the actual reason why "latch when released" is the standard behavior for a generic button is beyond me, but if you want your apps to behave in a way constant with all other GUI apps (I believe a generic button behaves this way across all operating systems), that is the way you program a generic button.

I just thought of an exception.  Occasionally browser buttons are set to act in a "latch when pressed" mode.

---

Notice that I said physical buttons - as in no mouse. Think of the power button on your monitor. The buttons on old style phones (or actually even the virtual buttons on new phones). You do appear to be correct that a lot of application buttons behave as you describe. In practice I think that the user won't recognize the difference. Perhaps there is a good reason to do latch when released of which I'm not aware. I will certainly take your advice into consideration in the future. Thanks!

[JÞB]

@Bill

Latch when released lets users mouse out of control focus without causing a value change.  That is why it is most common and provides a better UX.

[BertMcMahan]

Latch When Released is absolutely the de facto standard for UI buttons, but there are a handful of applications that buck that trend.

Physical buttons (as mentioned) nearly always "do something" when you press it, not release it, so applications that act similarly would need to latch when pressed. Many touch screen buttons work well that way- think of a bunch of directional arrows that move an XY stage around. It may just barely sluggish if you start the action when you release the button instead of pressing the button. A virtual keyboard would be the same; normal keyboards work when you press the button, not when you release.

Another instance would be for "flyout" style menus where you click down once to open a sub-menu, then hover over your option, then release it, but I've never actually seen one programmed like that in LV.

Again, to the OP, you definitely want to use Latch When Released most of the time as that's what users are used to. I just wanted to explain instances when that mode would be useful and why I'm glad it's there, even if I've never used it "for real".

[JÞB]

Nice reply Bert!

Of course, hardware buttons are terribly poor for the User eXperience! But, that is why software developers make the big Euros. 😉

Kudos, peanuts, Won, yen, punts, bucks, dinero, shells, whatever!  Send me some:)

[alexela]

---

@johntrich1971 wrote:

See if the attached does what you want. It's basically just a combination of what others have recommended.

Notice that there are no local variables, and I set the OK and Stop buttons to latch when pressed. 

For a simple program like this your current architecture is fine. For larger applications you may want to consider a more advanced architecture.

---

nice idea, but there as a long wait until the stop works once you press start. even more - you should click, wait and click again to vi to stop.

But thanks, learned some.

[alexela]

---

@JÞB wrote:

Latching booleans latch until they are read.  STOP Button is only read in the STOP Button value change event 

BUT, by the time the loop started waiting for an event the STOP Button Local Variable was read and returned a value of FALSE to the conditional terminal.  This is what we call a "Race Condition."

WORSE. In the OK Button value change event you depend on ANOTHER read of a STOP Button local variable to halt the inner While Loop  AND, the OK Button value change event locks the front panel until the event is complete so... you can't press STOP! This is what we call a "Deadlock."

Stop placing While Loops inside an Event case!  They simply don't belong there.  Never stop a loop from a local / global read of a latching Boolean. 

---

you are right about the deadlock, but what solution do you propose?

[alexela]

---

@Defaphe wrote:

---

@alexela  a écrit :

Greagory thanks, but how I start reading only when the Start button pressed?

---

You can switch to a producer/consumer architecture.

For each event you will add an action into a queue to do it in the consumer loop.

Then when needed you can add something into the queue even from the consumer loop to make a continuous reading.

---

playing with the idea.

It's kinda working, but not that well.

I still get a deadlock. to continuously read form visa i made read state (didnt find another way, better one). since loop stops after one iteration. 

Suggestion?

Thanks