From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
08-10-2005 07:45 PM
If you place one there, it floats on top and cannot be inserted INTO the cluster.
I have a user-interface issue which would be simplified by such a construct, but it can't be done.
I've tried 7.0 / Win2K & 7.1 / OS X. Neither works.
I think the tab basically just hides/shows the associated elements - why wouldn't the items in the tabs become elements of the cluster and still be hidden / shown by the page selector?
If I bundle a tab control and something else, I get a cluster with an ENUM in it, which is what I would expect.
Why is this restriction there?
Blog for (mostly LabVIEW) programmers: Tips And Tricks
08-10-2005 08:12 PM
Uhhh, because NI said so? Only reason I can come up with...
In any case, what are you trying to do?
Mike...
08-10-2005 08:37 PM
1... find out the philosophy or reasoning behind the restriction. Perhaps there's some reason I'm missing. "NI said so" is not very satisfying.
2... I have a (working) configuration editor program which has a lot of dependencies - if the HARDWARE TYPE control is set to SCXI, then the SCXI cluster is enabled (and other things are grayed out), if the HARDWARE TYPE is set to RT, then the RT cluster is enabled (and other things are grayed out), if the HARDWARE TYPE is set to CALCULATED, then the CALC cluster is enabled (and other things are grayed out). Now I am doing that with code and enabling / disabling umpteen different things in a front panel display.
If the HARDWARE TYPE was actually a TAB control:
There are certain items associated with a channel that are common to any hardware type, so those would be outside the TAB, but still inside the cluster that defines a channel.
I realize that I can do all this with code, but the TAB idea just seems a natural fit.
Blog for (mostly LabVIEW) programmers: Tips And Tricks
08-10-2005 08:47 PM
08-10-2005 09:03 PM
I don't see how that helps things, maybe I'm missing it.
Blog for (mostly LabVIEW) programmers: Tips And Tricks
08-10-2005 09:24 PM
Yes, the subpanel is just a way of embedding another VI's front panel as part of the caller's front panel. So yes, you would have one VI that would handle each type of data--which is a good thing. If by making one selection, you make certain screens nonapplicable you don't make them available for display, or make the applicable one visible in its stead.
You will need a little code for managing the subpanel itself, but typically not very much--checkout the subpanel examples. One caveat is that all the examples use the RunVI method to execute the subVI, and that can make passing data a bit more complicated. But you can also use call be reference to link to the subpanel VIs.
Basically, what I did was write a bunch of VIs that were responsible for loading, editing and resaving just one kind of data (and so were very simple routines) and then wrote a small shell that could call these small editor screens as needed.
Mike...
08-10-2005 11:49 PM
How about you keep the Tab control by itself on the panel, and then use its reference inside the cluster? Would that work for you?
-Khalid
08-11-2005 06:49 AM
Well, I could make it work, I suppose, but still, I would have to unbundle the stuff from the file into the display. When they change channels, I would have to bundle the display stuff up and store it, then unbundle the next batch for display.
Not impossible, but not as elegant as just putting the tab inside the cluster to begin with.
Blog for (mostly LabVIEW) programmers: Tips And Tricks