Event structure and a cluster - lagging input

[Mariahnova]

I am running into problem using a cluster of controls that I want to use with an event structure. Each control tied to an event case. Simple enough.

I used the cluster because the number of controls I am using is quite large. The problem is that I need to read the cluster to get the latest state before I unbundle and handle the event. The issue is that in order to pull this off, I need to use a local variable of the cluster for each event. Since the event structure could have ten or so cases, I end up with ten or so of the reviled and maligned local variables. 

The cluster has great advantages for what I am doing, but the local variable break old taboos in the LabVIEW style rulebook.

I am attaching a micro-version of the vi so you can see the problem. You have to imagine expanding this to a lot of event cases to see the problem. Below the simple front panel is the real front panel I want to work with just so you have an example.

So, am I wrong to use the variables and should I break the cluster and lose it advantages, or is this a valid use of the local?

For those of you that don't see why the locals are needed, just run the vi. You'll see that the direct wired version always lags one state behind the control. The reason is that on an event trigger (toggling the boolean) , the last state of the control is already at the event structure boundry. The event code executes immediately with the previous data. Putting the local inside forces the case to read the current state of the control and use the correct data.

Long winded and not much meat, but somebody must be bored out there and willing to jump into the fray.

[Ray.R]

The reason it does not follow the value changed is because the wire retained the original value before the value changed. 

You could use a reference to the control within the cluster and get it's value using a Property Node (see image below). Ignore code change from Local at top... <Used the code snippet tool.>

This might be an example where the (unrecommended) use of a Local would come in handy.

Let me think if there is a more elegant and memory conservative approach. 

[TCPlomp]

I would prefer this route:

Ton

<plug>

---

Ray.R wrote: Ignore code change from Local at top... <Used the code snippet tool.>

---

That's why you should use the Code Capture Tool

</pug>

[Ray.R]

which route?

the bottom one is going to give you the wrong value which is what he had as a problem..

OR

you probably mean something similar to what I posted, but got the reference from within the Event Structure... Yeah, I also prefer that one 😉

[TCPlomp]

---

@Ray.R wrote:

which route?

the bottom one is going to give you the wrong value which is what he had as a problem..

OR

you probably mean something similar to what I posted, but got the reference from within the Event Structure... Yeah, I also prefer that one 😉

---

The latter, it ties the event direct to the control triggering the event, and you could use it for several boolean controls.

Now in total retrospect, the event (Value Change) will also output the 'New Value', so there's actually no need for the local/reference.

Ton

[tbob]

Just moving the cluster inside the event will do the trick.  I always put the item that causes the event inside its own event case.

[TCPlomp]

---

@tbob wrote:

Just moving the cluster inside the event will do the trick.  I always put the item that causes the event inside its own event case.

---

That won't do it, since the questioner uses severel events for several controls inside the cluster.

Ton

[Yamaeda]

This is the proper solution, i'd say. I've had similar problems when generating several events at once, by using the internal value you get the ones sent with the actual event and not the current value.

[tbob]

---

@TCPlomp wrote:

That won't do it, since the questioner uses severel events for several controls inside the cluster.

Ton

---

I just re-read the original post.  You are right. 

But a simple local variable would do here.  There are times when a local variable is absolutely favorable.  It isn't taboo. I wish we would all stop discourage the use of local variables.  Instead we need to preach not mis-using local variables.  In this case, the local is perfectly acceptable and the best solution.  You are only reading from it, not writing to it.  No race conditions.

[Ray.R]

---

@tbob wrote:

I wish we would all stop discourage the use of local variables.  Instead we need to preach not mis-using local variables.  In this case, the local is perfectly acceptable and the best solution.  You are only reading from it, not writing to it.  No race conditions.

---

LOL!!  😄

It's like telling kids that matches are safe.  Well.. not quite..  People will abuse Locals as soon as they get their hands on them... ANd then the Frustrating Posts thread will grow as big as the Indian thread..  LOL!!  😄