LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Quick question on event handler

Hi everyone,

Here is my penny for your thought,

I have a GUI with an event structure to handle the users' clic.

On this GUI I place a toggle switch and I would like to be able to handle separately the change from high/low and low/high. Though I can't find where to handle the change of state in two separate cases.

 

Not sure if I am being clear ^^

0 Kudos
Message 1 of 15
(2,576 Views)

You use the Value Changed event and use a Case Structure inside to do something different depending on the "New Value".


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 2 of 15
(2,569 Views)

If you are using a value change event then you can configure the event to return the new value.

 

That value can be used to drive an case structure where if the new value is TRUE then the transition should be false to true etc.

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 3 of 15
(2,566 Views)

On your GUI is a Boolean Toggle switch, call it "Toggle".  You have an Event Structure, with a Toggle (Value Changed) Event.  Inside the Event Structure (for that Event), you can do one of the following:

  • Put the Toggle control and wire it to a Case Selector.  The "True" case corresponds to "False-to-True" change, and the "False" case corresponds to the "True-to-False" change.
  • Use the "NewVal"  property of the Event Structure (see Snippet) if you don't have the Control itself available.

Do you understand how the "mechanical actions" of Boolean Controls work?  If not, look it up, or build a little test VI and watch it work, noting when the value changes from False to True, from True to False, and under what conditions it changes itself back to the default value (which, for Booleans, is False).

Boolean EventBoolean Event

Bob Schor

 

Message 4 of 15
(2,502 Views)

Must resist the urge to mention the corner case where Bob's assumptions don't hold.......

 

Spoiler
When using a Value Signalling Property node (setting the value) the presence of a "False" does not neccessarily mean that the previous state was "True".  Same goes for the opposite polarity.  Whether this is a problem or a useful debugging opportunity, that's purely a point of view.

Dang it.

Message 5 of 15
(2,471 Views)

Must resist the urge to correct myself.....

 

Spoiler
Depending ont he mechanical action of your boolean and where the terminal resides, you may end up with some very different issues with your code.  The "resetting" of some mechanical actions of buttons only happen then the terminal is read (Within the event structure in Bob's example).  This is the recommended way of doing things, but if you rely on this, make sure to put a comment in there stating this otherwise someone else (like yourself in two years time) comes along, moves the terminal and spends two days tracking down a self-inflicted bug.

Dang it.

0 Kudos
Message 6 of 15
(2,470 Views)

Must resist the urge to make yet another obscure and hugely niche remark

 

Spoiler
Default value of a boolean is not per definition "False". It's only default "False" by default (makes complete sense, right). You CAN set the default of a boolean control to be "True" upon which case, the "resetting" of the switch becomes reversed for latching actions.  i.e. when you choose "False" and then read the terminal on the BD, it will go back to "True" as opposed to the opposite way around.  This is a great obfuscation which can lead to some head scratching when people encounter it for the first time.

Dang it.

 

Three strikes and I'm out.

Message 7 of 15
(2,469 Views)

On the topic of mechanical action...

 

I have pretty much switched over to "Switch when Pressed" and put the terminal in the event case that handles that value change. I then use a property node inside the event to set it false again. This allow me to insert a very short delay just prior to resetting it. The delay makes it obvious the button was pushed. Without the delay I have had a customer report "the button is not working" only to find out that the button was working but it ws reset so fast they did not see the state change.

 

Ben

 

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 8 of 15
(2,463 Views)

@Ben wrote:

On the topic of mechanical action...

 

I have pretty much switched over to "Switch when Pressed" and put the terminal in the event case that handles that value change. I then use a property node inside the event to set it false again. Ben

 


I would say the "Switch When Released" would be preferable and is comparable to the typical to way Windows typically handles buttons.  The "When Released" allows you to slide off the button and not have the button actuated if you change your mind mid-press.

Message 9 of 15
(2,456 Views)

@Intaris wrote:

Must resist the urge to make yet another obscure and hugely niche remark

 

Spoiler
Default value of a boolean is not per definition "False". It's only default "False" by default (makes complete sense, right). You CAN set the default of a boolean control to be "True" upon which case, the "resetting" of the switch becomes reversed for latching actions.  i.e. when you choose "False" and then read the terminal on the BD, it will go back to "True" as opposed to the opposite way around.  This is a great obfuscation which can lead to some head scratching when people encounter it for the first time.

Dang it.

 

Three strikes and I'm out.


Hahaha. That's a beauty. Have never seen that one in the wild before.

 

 

0 Kudos
Message 10 of 15
(2,449 Views)