03-04-2015 08:03 PM - edited 03-04-2015 08:07 PM
I want to hear some feedback about this approach.
I'm creating a relatively big program, and I like to use offscreen indicators / controls as "local variables".
I'm thinking of turning this into a cluster - typedef, called "local variables" which I can then wire into differnet VI's, and it cleans up the code quite a bit (but adds overhead and makes it less obvious what's going on ).
What do you guys/gals think about this approach?
Solved! Go to Solution.
03-04-2015 08:15 PM
What are these "variables" used for?
In general, using hidden front panel controls just for local variables is a bad habit to get into. There are likely much better ways, usually depending on your exact application. Alternatives include User Events, Queues, Notifiers, Data Value References, and Global Variables.
03-04-2015 08:19 PM - edited 03-04-2015 08:21 PM
These are copies of data that are used by multiple subVI's. The user has no reason to view them. This has nothing to do with streaming data, or dynamically-determined outcomes (mostly they are static).
Are you saing global variables are a better idea than local?
I think this system exchanges overhead for nice top-level abstraction. (I.e. instead of passing "tab ctrl reference" "Device SN string" ...etc...more params, I can just pass-by-val a single copy of my "local variables" typedef.
Why is using hidden front panel controls just for local variables a bad habit to get into?
03-04-2015 08:26 PM
@LennyBogzy wrote:
I can just pass-by-val a single copy of my "local variables" typedef.
Why is using hidden front panel controls just for local variables a bad habit to get into?
You are just making a lot of data copies with both of those things. And the hidden items makes it so that they are only accessible in that VI. So if you are making the extra copy anyways, might as well make it a global so that the subVIs can just access them directly.
03-04-2015 08:37 PM - edited 03-04-2015 08:42 PM
Right, it certainly increases overhead but who cares? Machines have so much ram these days. For more overhead, II have a elegant, minimalist and abstracted, top-levelVI. Globals would spread this across multiple files, i'm weary of that.
As far as only being accessible to that VI maybe that's a good thing? at least this way I get scope control..
03-04-2015 09:01 PM
@LennyBogzy wrote:
Right, it certainly increases overhead but who cares? Machines have so much ram these days. For more overhead, II have a elegant, minimalist and abstracted, top-levelVI.
No. Nothing is elegant or minimalist. And it certainly isn't abstracted.
@LennyBogzy wrote:
. Globals would spread this across multiple files, i'm weary of that.
And PC's have terabytes of hard drive space these days. So why would you care about multiple files.
03-04-2015 09:30 PM - edited 03-04-2015 09:36 PM
"No. Nothing is elegant or minimalist. And it certainly isn't abstracted."
What? How do you mean?
As I stated, I go from wiring a bunch of stuff into VI"s to wiring a few generic types (a collection of generic typedefs). How is that not the exact definition of abstraction, minimalism, and elegance?
And it's obviously not the number of files from a storage perspective that is undesirable for me, if anything it's the uncontrolled scope issue...
03-04-2015 09:39 PM
You said you need lots of hidden controls and local variables to access them. That certainly isn't minimalist.
And no one on the forums here who have any experience architecting LabVIEW applications believe that local variables are elegant.
As for abstraction, I don't know what you think the definition is, but none of this would apply.
03-04-2015 09:41 PM - edited 03-04-2015 09:44 PM
My definition of abstraction is taking something specific, and making it more generic i.e. abstract (think abstract class). That's exactly what this is. (A car is a more abstract version of honda).
03-04-2015 09:43 PM - edited 03-04-2015 09:46 PM
But you are not passing generic UI controls. You are just collecting a bunch of data in unused controls within the VI.
If you really want to talk about classes, then I suggest you start thinking in terms of object oriented programming. Playing with local variables is about as far away from that as you can get.