Programmatically trigger button with latch action without using user events

[peter111]

There are many posts in the forum about triggering programmatically a button with latch action and all they point to one solution - using custom user events. For complex projects this is maybe the best solution, but for simple and small projects sometimes it's too sophisticated (creating the event infrastructure requires some time and experience).

Here I'm sharing one another solution to trigger programmatically the buttons with latch actions which is not using events, but in the same time it's fully event driven solution (not using data polling).

The idea is to use "sacrificial" boolean dummy control (like LED), add change value event from this dummy control to the event of the target button and to call somewhere in the code the property node Value(Signal).

The effect is that when pressing the target button (with latch action) or when calling property node Value (Signal) the same event will be triggered.

The dummy control itself could be hidden so it has no impact on front panel. As the solution is event driven it has no impact over the performance of the VI, it has very small additional code and it's simple for understanding.

 

[Bob_Schor]

I, personally, think this is a bad idea.  You are introducing unnecessary complexity to get around additional functionality that NI built into the Boolean Control to give it the useful "Latch When Released" property that makes these buttons ideal for "Push to trigger an Event-driven Action".

When you try to "subvert" this design of a control meant only for User Interaction by asking to "programmatically" push it, you end up having to invent complex schemes such as the one you propose, with "hidden" controls and fancy code that will leave people scratching their heads, even if you do document it carefully in the Block Diagram.

An "easier" way to "Push your Button" and "Program it, Too" is to change the Button's Mechanical Action to Switch when Released.  In the Event Loop for the Value Changed Event for the button, simply drop a Local Variable for the Button and wire "False" to it, effectively resetting it and duplicating the action that LabVIEW does for you if you used the "Latch when Released" Mechanical Action.  You'll find that you can now set a Value (Signaling) Property for this Control.

It is still a Kludge, and should probably be avoided, but it is easier to understand.

Bob Schor

[natasftw]

The toughest part of using events is understanding what events are.

You've kept the hard part, added some extra nonsense to it, and posed it as easier.

Really, what you're doing here is teaching bad practices rather than encouraging learning and understanding the concept they should be using.

Keep in mind, common practices are good for a variety of reasons.  The obvious is they're vetted by the community and found to work best.  The less obvious is using these makes your code more readable.  If you're doing the things that other developers do, they can easily look at your code and recognize it just as you can look at their code.  When you start using hidden controls and "dummy" logic, you make your code far tougher to maintain.  Now, you're not able to bring on other developers easily.  The ramp up will be much greater as they try to understand the things you're doing to get around some of the basic concepts.

This, as a whole, is punishing yourself. Please don't do that.  And please, anyone reading this, don't follow this lead.

[peter111]

Good points! I have to agree that all what you said is correct and this approach with dummy control events have to be avoided.

[billko]

---

@Bob_Schor wrote:

I, personally, think this is a bad idea.  You are introducing unnecessary complexity to get around additional functionality that NI built into the Boolean Control to give it the useful "Latch When Released" property that makes these buttons ideal for "Push to trigger an Event-driven Action".

When you try to "subvert" this design of a control meant only for User Interaction by asking to "programmatically" push it, you end up having to invent complex schemes such as the one you propose, with "hidden" controls and fancy code that will leave people scratching their heads, even if you do document it carefully in the Block Diagram.

An "easier" way to "Push your Button" and "Program it, Too" is to change the Button's Mechanical Action to Switch when Released.  In the Event Loop for the Value Changed Event for the button, simply drop a Local Variable for the Button and wire "False" to it, effectively resetting it and duplicating the action that LabVIEW does for you if you used the "Latch when Released" Mechanical Action.  You'll find that you can now set a Value (Signaling) Property for this Control.

It is still a Kludge, and should probably be avoided, but it is easier to understand.

Bob Schor

---

A version of this is the ONLY way to do this if your event is responding to a button in a different VI.  (In this case you bring out the control ref and create a value property node and set the value to FALSE.)

[paul_cardinale]

---

@peter111 wrote:

There are many posts in the forum about triggering programmatically a button with latch action and all they point to one solution - using custom user events. For complex projects this is maybe the best solution, but for simple and small projects sometimes it's too sophisticated (creating the event infrastructure requires some time and experience).

Here I'm sharing one another solution to trigger programmatically the buttons with latch actions which is not using events, but in the same time it's fully event driven solution (not using data polling).

The idea is to use "sacrificial" boolean dummy control (like LED), add change value event from this dummy control to the event of the target button and to call somewhere in the code the property node Value(Signal).

The effect is that when pressing the target button (with latch action) or when calling property node Value (Signal) the same event will be triggered.

The dummy control itself could be hidden so it has no impact on front panel. As the solution is event driven it has no impact over the performance of the VI, it has very small additional code and it's simple for understanding.

 

---

A better solution is to just change the boolean from latching to switched, then in the Value Change event for it, write  FALSE to a local variable for the boolean.