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.

LabVIEW

The best way of discouraging Local Variable Abuse (LVA) is to discourage Local Variable Use. 😉

As mentioned there are occations where they definatly are the best and fastest solution, but they're the - "Exception that proves the rule."

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems

Message 11 of 11

(403 Views)