Thanks for your ideas...
I think that this would lead to a much more complicated program. References are good for batch changing properties of controls, making cleaner top level code, etc, but overuse can create some headaches.
What is overuse? My goal is not just cleaner top level code, but a sterile top level. IMO the ideal case is just controls/indicators and sub vis... no structures or primitives.
Accessing data from references is slower,
I have heard this many times, but here... slower than what? In the case of something like color, there is no alternative. So that just leaves us with the oft mentioned value property. I agree that it is poor practice to use this for passing data around an application, but that is not what I am trying to do. Is it slower to use the value property instead of wiring directly to the indicator when what you are after is a panel update anyway?
and as you have already mentioned you can get race conditions.
The specific race condition is that I have an array/cluster of indicators and I want to update only one element. This requires a read/modify/write, but it requires that no matter where you try to do it, so something has to protect the operation, be it some sort of GOOP code or a wrapper vi. In either case it is not a show stopper... race conditions are easy to handle if you can spot them.
There are also caveats on closing and opening references that need to be obeyed
This is not the case for my application... I do not explicitly open any references... they are all static links made with Create>>Reference and I intend for them to persist for the life of the application, so labviews own clean up when the application closes is sufficient. Also, I am not talking about thousands, or even hundreds of them... just as many as I have controls on the front panel. And any controls that I have in arrays are linked to a single ref.
and probably other negatives for using refs in this way.
What are they? I am not trying to be a meanie or argumentative... you are making me think carefully about what I am trying to do, and I appreciate that very much.
[NOTE: you can also use event driven state machines etc and although they seem "complicated", these too are really elegant solutions to application design under LV.]
Nearly every app I write has at least one of these, usually more. I prefer the queue to the new dynamic events, mostly because of limitations on event implementation. (I for one was very disappointed with the user events as well as the dynamic event registration, but that is another thread altogether). The queue datatype is a cluster with an enum and a variant. The enum specifies the event and the variant has the event data, if any.
You can abstract the GUI and the underlying modules, not running in the UI thread, etc, etc, etc.
But, in this case, it has to run in the UI thread anyway. The point of the entire thing is how to update UI indicators.
There are negatives too ... more VI's, more memory usage, slightly slower execution, but that's cheap compareed with programming debugging time. AND these negatives are really really really minor and not noticed unless you're pushing tin ;-)
I agree that memory/execution speed are easily traded for less debugging/adding feature headaches. That is, in fact, what I am after. And at least this far in my career, I (thankfully) have never had to write an app to push tin :)) Thanks again for your feedback
George
