Cannot get latch mechanical action on boolean button inside a cluster

[Blokk]

---

@JensG69 wrote:

Hi,

I keep saying "alongside" since my example contains several events for the differents latched buttons inside the cluster.

We all agree that a latched button will only reset when LabVIEW according to dataflow accesses the terminal. Since my example contains several events I cannot place the cluster inside every event case. Only solution: Place it parallel to the eventstructure (or in a flat sequence after the eventstructure) and hope that the code inside the events does not wait.

Cf. attached VI:

Regards, Jens

---

Then this is a bad design choice from the beginning. Use a single Event Case for your cluster. Simple and compact. I think it is not good to show such examples specially to beginners, since they will learn to use it...

EDIT:

here is a snippet using a single Event Case:

[JensG69]

@Blokk:

I certainly agree that using several latched buttons (or even one latched button) inside a cluster is not the optimal design choice. But alas it seems the OP did something like this and now has problems. I only try to give a solution of what I believe is the source of the problem in the VI of the OP. Unfortunately he did not upload his code up to now so we are all guessing.

I disagree that it is always a bad design choice to define events for elements of a cluster. I think defining events for elements of a cluster makes the code more readable.

Regards, Jens

[Blokk]

---

@JensG69 wrote:

@Blokk:

I certainly agree that using several latched buttons (or even one latched button) inside a cluster is not the optimal design choice.

I did not say this. I said it is a bad design not putting the Cluster control into a (single) Event case. There is nothing wrong to use several Boolean buttons (with "Latch until release" mechanical behaviour, as this is the common usage) inside a Cluster, I do this all the time!

I disagree that it is always a bad design choice to define events for elements of a cluster. I think defining events for elements of a cluster makes the code more readable.

Well, in my opinion the code is more readable if you use a single Event Case for a cluster, since we have this option. You read out the control in the proper place, and it is also very easy to compare old/new values and get the index of the button which value got changed. I cannot imagine a more simple way to do this right now...

---

[Bob_Schor]

How silly.  If you have a Cluster whose elements are all Latch until Released Booleans and you do (as GerdW and I both suggest) put the entire Cluster inside its own Value Changed (for the entire Cluster) Event,  Since you can Mouse Down on only one button at a time, any Button Click will "turn on" exactly one button, and it should be pretty trivial exercise to figure out which one.  You can do a single Cluster Element, or the entire Cluster in an Event, but be sure that the entire Cluster is in each Event that involves it.

Don't they drill this idea into discussions of Boolean Latches and Event Structures any more?

Bob Schor

[billko]

You can always emulate a latched button by setting it to switch when released, then setting the value to FALSE by using a property node in the event case.  This would work well if the button is inside a cluster.

[Blokk]

---

@billko wrote:

You can always emulate a latched button by setting it to switch when released, then setting the value to FALSE by using a property node in the event case.  This would work well if the button is inside a cluster.

---

In such case, use a local variable to set the value of the control, better to avoid property nodes for setting control values...

[Yamaeda]

As to using 1 event for a cluster or many for its elements, i'm 50/50. It depends on what's happening inside the event and how messy it'll be. So basically, the tidier one.

/Y