@altenbach wrote:
I would place a shared control outside the tab structure. You can always disable it based on the tab value if it should not be used when certain pages are selected.
I wouldn't use a Tab Container at all! Yes, I still hate tabs! My common approach to avoid the ungodly Tab container is to use a subpanel container instead and select the VI to load into that subpanel container with a custom Radio Button that looks and acts exactly like a tab page selection.
<EDIT>: The radio button CAN act exactly like a Tab page selector. But, you can also programmaticly access the enabled <enum> property for each Radio control button itself to hide some functionality based on user authority or prerequisites. Tab page selection has no comparable feature for the page selectors enabled state. Plus, I could choose to undock or even launch the sub.vis as Floating or Modal panels.
</EDIT>
This puts the code to handle each page in its single responsible vi and permits main.vi to concentrate on simply displaying the chosen groups of user interactions without needing to handle the minutiae of what and how each group interacts with the user. Reusable: Check, Scaleable: Check, Organized, readable and Maintainable: ✔✅🛫
And, of course, you can even use a common control on any of the subpanel.vis that need access to that common data value or, exclude that control wherever it isn't useful.
This approach easily address the original poster's problem without clumsy control visibility property management code or sloppy overlapping objects on the front panel of Main.vi
I hate tabs
"Should be" isn't "Is" -Jay
