Event Structure

[aah31]

When I click a button linked to the event structure that is executed on value change that event case executes exactly twice every time, any thoughts. I have been using event structures for years and never came across this before.

[george seifert]

When I click a button linked to the event structure that is executed on value change that event case executes exactly twice every time, any thoughts. I have been using event structures for years and never came across this before.

Is the mechanical action set for "Switch until released" or "Latch until released"? That will do it.

George

[crelf]

It does change twice - goes to true when the button is down and then back to false when the button is released.

Anyway, I think it's better form to use "Mouse Up" <- this is the more accepted practise (allows the user to change their minds after the mouse down by dragging thier pointer off the button). There are exceptions to the rule though: use "Mouse Down" for links and anything that's related to stopping something so it happens as soon as possible.

[EricLarsen]

Anyway, I think it's better form to use "Mouse Up" <- this is the more accepted practise

Interesting, never thought of that. What mechanical action do you use for Boolean controls in this situation?

[ooth]

It does change twice - goes to true when the button is down and then back to false when the button is released.

Anyway, I think it's better form to use "Mouse Up" <- this is the more accepted practise (allows the user to change their minds after the mouse down by dragging thier pointer off the button). There are exceptions to the rule though: use "Mouse Down" for links and anything that's related to stopping something so it happens as soon as possible.

I second this idea. I always use mouse up for push button events.

[smenjoulet]

Anyway, I think it's better form to use "Mouse Up" <- this is the more accepted practise (allows the user to change their minds after the mouse down by dragging thier pointer off the button). There are exceptions to the rule though: use "Mouse Down" for links and anything that's related to stopping something so it happens as soon as possible.

I second this idea. I always use mouse up for push button events.

Huh???

I don't tend to disagree with Chris, but I just don't buy the argument in this case.

It may be "better form" to use 'Mouse Up' if your mechanical action is NOT 'Switch/Latch when Released' to avoid double events, but in my opinion, the best form is to use 'Value Change' in conjunction with the 'Switch/Latch when Released' mechanical action. There are always exceptions depending on what you're trying to do, but for me this combination is the best method when using buttons on a GUI in most cases. I am after all changing the value.

'Mouse Up' certainly works, but you can get quirky behavior. Have you ever considered that you can click a blank area of the panel, move the mouse over a button, release the mouse button, and BOOM... fire an event! Hardly desired or intuitive action.

And if you are concerned about the user changing his/her mind, the 'Switch/Latch when Released' provides the capability to drag the mouse off the button and release without firing the event. In fact, the button displays its previous indication when hovered off as an indication to the user that the action won't be performed. This is standard operation for most, if not all, Windows (and I assume MacOS) buttons.

Just my opinion, and as in anything I'm open to discussion and possible persuasion.

-Scott

[jdunham]

Huh???

...

'Mouse Up' certainly works, but you can get quirky behavior. Have you ever considered that you can click a blank area of the panel, move the mouse over a button, release the mouse button, and BOOM... fire an event! Hardly desired or intuitive action.

And if you are concerned about the user changing his/her mind, the 'Switch/Latch when Released' provides the capability to drag the mouse off the button and release without firing the event. In fact, the button displays its previous indication when hovered off as an indication to the user that the action won't be performed. This is standard operation for most, if not all, Windows (and I assume MacOS) buttons.

I agree with Scott. I've been using Value Changed for years with booleans and it always works well for me, including handling the edge cases Scott just mentioned just as the end-user would expect. Further, if you have set Key Navigation for the buttons, then Mouse Up is not going to fire and the user may wonder why your code doesn't work. I suppose you could program keypress events to duplicate the Key Navigation functionality but it works fine if you do it the easy way. Also with Value Changed, you can easily simulate the button press with the Value Signalling property if you need to test your code or chain events.

Under normal configuration and use, you do not get more than one Value Changed event for each button press. I'm not sure what is causing the OP's problem if it's something other than what George suggested.

Jason

[aah31]

Thanks to all,

I also agree with Scott. I kept the value change and used the appropriate form of mechanical action mentioned. Everything worked out great. Thanks Again.

-Anthony

[TG]

Thanks to all,

I also agree with Scott. I kept the value change and used the appropriate form of mechanical action mentioned. Everything worked out great. Thanks Again.

-Anthony

The only one that I use that keeps me out of trouble is the value change event and switch when pressed.

I create a local of the button use it to reset the control in the true case. And I don't care if it takes a little longer because it is a GUI event anyway.

I only care that it is foolproof with GUI stuff. Of course internal to LabVIEW its possible to do it other ways.

I learned to stay away from Mouse up for GUI push button stuff.

This is the only configuration I have used that has not come back to bite me later with unexpected behavior.

I know Im just a dummy for not understanding fully how LabVIEW works under the hood but I use what works for me