09-06-2006 11:02 AM
09-06-2006 11:09 AM
Thanks Ben,
09-06-2006 11:20 AM - edited 09-06-2006 11:20 AM
Hi Ray,
I THINK I heard him allude to it, but I do not remeber where.
Here are some screen shots of a "Visability Controller" that is a little more complicated that what I think you need. It allows for the user to "Back out" so it has to remember the previous state of the FP objects.
Here goes;
At start-up all of the control references are saved in a shift register.
When I have to change the visability, I can invoke one of the actions as shown below. (Please note the New User" tab is set visable).
This effectivelt moves all of the property nodes out of the main and into a single place and should make it easier to manage the screen state.
Let me now if you still need more help!
Ben
Message Edited by Ben on 09-06-2006 11:21 AM
Message Edited by Ben on 09-06-2006 11:21 AM
Message Edited by Ben on 09-06-2006 11:23 AM
09-06-2006 11:25 AM
You just gave me an idea 😄 😄
I think I can make a modified version of this work..
=== dissappearing to the world of espresso before attempting a vi transformation surgery ===
Thanks Ben!
Ray
09-06-2006 11:56 AM
And just to add one small twist:
All those individual shift registers still occupy a lot of screen real estate while developing. A possible alternative is to simply have one shift register with the array of control references. For each of the action states, you'll need to have a method for identifying which indices to act on. This becomes a new problem to solve, but one whose solution may be more compact visually.
Hard-coding the indices seems like asking for trouble. I personally never show controls' captions, so I might embed some kind of grouping I.D. into the caption text of those controls. Then the subvi containing the array of references can just loop through them while performing some string matching to determine which controls are 'eligible' for the specified action.
Hmmm. Still seems kinda clunky. Still based on hard-coded info. Sure seems like there ought to be a more elegant way to make this kind of group i.d., but I'm coming up blank. (I'm assuming here the general case where the logical groupings can't map nicely into clusters, either because of front panel layout reasons or because some individual controls need membership in multiple groups.)
Good topic - I'd also be interested in approaches that lead to a fairly compact solution.
-Kevin P.
09-06-2006 12:17 PM - edited 09-06-2006 12:17 PM
Kevin wrote "Still seems kinda clunky."
I agree!
But....
Let's put things in perspective. Before control reference were available we used to have to do this work in the GUI !
Compared to that, this appraoch make sthe GUI BD look elegant.
I too, would like to hear more voices share their wisdom on this topic!
Trying to push the LV envelope, one question at a time,
Ben
PS A more compact approach could use list of control names to show or hide depending on the requirements, BUT, that woudl make the code maintanence a text based chore and take all of the fun out of it.
Message Edited by Ben on 09-06-2006 12:20 PM
09-06-2006 12:38 PM
09-06-2006 02:55 PM