George,
I use this technique frequently for large control systems where multiple threads
update their corresponding front panel data. I have even toyed with
the idea of allowing the threads to detect their own events (instead of the launching
thread detecting and messaging) with the dynamic events introduced in 7.0. I've tried
to show some colleagues the merit of such a design but have been met with some
resistance, so it would be interesting to see what others think. I'm not sure that I
understand what race conditions you are refering to. my threads just use the globally
stored control references to update status information.
J Adam Crain
Goodman Lab
UNC-CH Dept Physics and Astronomy
Subject: Good Programming Practice?
From: "George Gatling (Contractor)" <[EMAIL PROTECTED]>
Date: Thu, 19 Feb 2004 14:40:54 -0500
I have explored several ways to modify front panel data in labview, and
many of them seem to complicated or too flat (huge toplevel diagrams). Now
I am toying with a new idea... On the top level vi I load references to
all of the indicators and controls into a global and then read/write to
them via their reference lower down in the hierarchy. If there are
possible race conditions I build a wrapper vi to protect read/modify/write
cycles (one per front panel object). I realize all of this is running in
the UI thread because I am using refnums, but it would be anyway because
all of this is about the front panel. Now... what are the downsides?
George Gatling
Applied Technology Division, SFA Inc.
Space Physics Simulation Chamber
US Naval Research Laboratory
202-404-5405 (phone)
202-767-3553 (fax)
If trees could scream, would we be so cavalier about cutting them down?
We might, if they screamed all the time, for no good reason. --Jack Handy
