Why can't I put a TAB control into a cluster?

[CoastalMaineBird]

Why is it that a cluster on the panel will not accept a TAB control inside it?

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?

[mikeporter]

Uhhh, because NI said so? Only reason I can come up with...

In any case, what are you trying to do?

Mike...

[CoastalMaineBird]

what are you trying to do?

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:

• It would still be an ENUM, for use elsewhere in my program.
  
• The enabling / disabling would be handled by the tab, simply by putting the SCXI stuff in the SCXI tab, the RT stuff in the RT tab, etc. No code necessary.
  
• Performance would be better, I think. The display is actually an array of "channels", each one of which has a hardware type. So every time the user wants to look at a different channel, I have to do the whole enable/disable trick, because you can't disable an item in an array without diabling it for ALL array elements (You don't have an array of properties, you only have an array of data values). But if a TAB was there, each array entry would have its own setting, without any code.
  

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.

[mikeporter]

As near as I can tell, there isn't any philosophy behind it--it's just what is...

Concerning your problems, a way that I have handled that sort of situation in the past, sounds sort of like what you were wanting to do with tabs, but I used subpanels. Each subpanel services one function (SCXI, RT, etc). With this scheme, the "editor" application became little more than a framework for calling screens that did the real work embedded in a subpanel.

Works nice, modular and easy to expand...

Mike...

[CoastalMaineBird]

But don't the subpanels need a VI behind them? There would need to be a subVI for SCXI, a subVI for RT, etc., etc.


And you would STILL need some mechanism for showing / hiding the subpanels, or inserting / removing them from the subpanel.

I don't see how that helps things, maybe I'm missing it.

[mikeporter]

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...

[Khalid]

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

[CoastalMaineBird]

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?

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.