Tabs?

[cirrusio]

I wonder if anyone has anythoughts about this.  I am currently in the final phases of developing a data acquisition system and am now refining the GUI for the first draft.  The system itself requires virtually no user interaction, but the user will be monitoring the interface regularly to make real time decisions about the course of experiments.  I want to reduce the clutter on the main interface, putting those few controls that might actually be used during a regular experiment on the main interface and then providing a button or menu item for accessing the GUI for a main control if the user feels the need to adjust some of those parameters that are usually configured for one time.  This obviously requires some sort of global VI to communicate between the two interfaces and keep track of the experimental parameters.  Until now, this is the path that I have taken.  For some reason, I have been adverse to the idea of using tabs (just an aesthetic thing).  But now I am vacillating - does anyone here have any thoughts?  When would be the best time to use tabs?  Everytime?  (I have seen some GUIs with out of control tab set ups and I would like to avoid this)

Cheers, Matt

[gosenbach]

Matt,

I regularly make use of tab controls.  The secret to making them look good is to hide them.  I setup all my tabs and hide the tabs and make the entire tab control transparent.  I then setup some menu/toolbar buttons or run-time menu items and will switch the tabs for me in the even structure.  Just create a local variable for the tab control, right click, create constant, and you get an enum with all of the tabs.  It's simple to setup and looks great.  It has the effect of making all the controls on the screen just magically change.

Greg

[spsuamin]

i second goose. i used to do the multiple vi interfaces or even using a subpanel. I feel the tabs method is ten times easier and more manageable. All you need to worry about with configuring the tab is making sure the first you the user sees is properly set to all the defaults. Worry about setting the other's to their defaults when you switch to them. I also just hide the tabs and sometimes I make the tab element itself completely transparent that way if I do want something to show up on all the tabs without having to copy and paste it on all of them I can just put the object in the back, move the tab object to the front and then make it transparent.

[gosenbach]

Its is also easy to get controls on all the tabs by creating it off of the tab control and then "floating" it over the tab control by moving it into position with the arrow keys.  If you do not want it on all the tabs, but more than one, you can show/hide the control as approprate in the same event case you are using to switch the tabs.

[rex1030]

I like the first comment about the best way to make tab controls look good is to make them invisible. How sad. I love tab controls because I tend to have to program for laptops and I can fit more controls into less screen real estate. There is so much potential there but I feel like my hands are so tied trying to make them look sharp. Maybe they will improve tab controls in future versions of labview.

Wish they would:

1. Allow setting of the color of active or inactive tabs so it's easy for the user to tell where they are.

2. Allow sizing of the tab label area so decorations could be added.

3. Allow more control over the look of borders of tabs.

4. Allow the changing of visible or invisible or disabled/greyed tabs

5 Updated 'System' tab to be updated to XP or ideally windows 7 look

[cirrusio]

I realized that I never replied to this thread to show what I ultimately came up with. The project changed significantly over the last year and it ended up that I needed to be able to control and view the state of two instruments on one host with which I was communicating with via TCP/IP.  Based on what I was seeing here, I went with a tabbed layout, hiding the tabs themselves and replacing them with buttons.  You can see that I am using the system controls for the most part (including those from the Missing System Control Suite put up by Simon).  Anyway, here are some screenshots.  For the most part, I think it came out ok.  Thanks for all of your input.  This group is awesome.

Cheers, m

[Bill_in_Detroit]

Matt:  Very Nice!

Bill - LabVIEW Certified Developer

[Anil_Reddy]

hey..one simple question..did you use local variable to select tabs or Property node. I had some problem in selecting tabs when I used local variables but it worked perfectly with property node. Did you notice anything as such?

[cirrusio]

Anil,

I used local variables (see below):

In the above case, there is no change of state for the variable (swDisplay is a cluster of booleans - the buttons on the front panel mimicking the tabs). 

In the above case, there is a change of state and the page is changed to the page indicated by index i (this is the index of the button which was selected).

I have seen no problem with using local variables (and these should be better to use than property nodes, but in this case the performance issues are not particularly relevant).

Cheers, Matt

[Taggart]

I'm glad that worked out for you.

Lately I've come to dislike tab controls for all but the simplest UIs.  I now favor subpanels.

The reasoning:

1.  Simpler Block Diagram.  Using a tab control forces you to have all the controls on the same block diagram.  Not too bad if you don't have a lot of controls, but I now working on a project (which someone else wrote) which has 17 tabs and over 1000 controls.  That makes for one cluttered block diagram.  You might say "oh well my application is small and simple".  It may be now, but then again the customer never knows what they want, right? And there is always scope creep, which as much as I hate and fight it, it pretty much a way of life for me - I work for internal customers who hate to write things down because then they can't change their mind every 5 seconds.

2.  More easily expandable. If you manage subpanels right, adding another screen should be easy and may not even require making any changes to your main UI vi.

3.  More modular. - with everything in 1 block diagram it is easy to make changes to one screen and break something else.

4.  Better adapted to multiple developers.  If each screen is a different vi, then you can assign 1 developer to each and not have to worry as much about conflicts when checking stuff back in.

5.  Dynamic loading - If you manage subpanels right, you can dynamically load new UI modules whereas with a tab everything is defined at edit time.

Downsides:

1.  Slightly more Overhead.  Managing the subpanels takes some overhead - but if you use classes and dynamic dispatching you can put all that in the parent class.

2.  Resolution/sizing issues. You have to use some care in this area, but it can be done.

I highly recommend that you look into subpanels and put the time into learn about them.  They are quite powerful.

Message was edited by: Taggart (I changed the title for #5).