What are some clever uses for the Tab Control

[Jim Kring]

Here are some ways that I use the tab control:

1. Configuration/Options Dialog -- Put configuration parameters for different categories (or aspects of the software) into different tabs. This mode of use is probably the most common.

2. Wizard Screens -- Use the tab control for building a Wizard user interface, where the tab's are hidden (the user cannot click on the tabs). Each screen of the wizard is in a different page of the tab control, and the pages are programmatically changed, as the user presses the Next or Back button.

3. System (Dialog) Raised Box Decoration -- Since there are no System (Dialog) raised-box decorations, I will commonly use a Dialog Tab Control with one page and the tab hidden, as a subsitute for a Dialog Raised Box.

4. A Better "Grouping" Mechanism -- An extra benefit of #3 is that the controls inside of the single page tab control are now grouped -- without actually having to use the Group feature -- and can be moved around by simply moving the tab control. If you use a Modern (3-D) or Classic (2-D) tab control, you can even make the tab control transparent.

Can you think of other good uses for the tab control?

[PJM_labview]

I have seen people using it for dumping stuff they dont want to see on the UI

5. Garbage collector -- Use a 2 tab control, put everything in the first one that the user should not see (for example VI inputs, VI outputs ...). In the second tab put the UI controls that the user is expected to interact with. At run time make sure the second tab is selected and that the user do not see the tab control.

PJM

[gleichman]

6. Show/Hide Controls -- In UIs that have CPU intesive indicators (Tables, Graphs, ect.), I have a show/hide option that I used to implement with the visible property, but I now use tabs. The added bennefit is that I can put a message or picture in the empy tab saying that the indicators have been hidden for faster execution.

Alan

[jeffwass]

Can you think of other good uses for the tab control?

I was actually just about to ask this question in general, and after coming to LAVA User Group today, I found you happened to asked a nice segway question yesterday. So here's my question - does anybody know how to ADD controls to a tab page programmatically? I can see how to READ the controls on any page of the tabs, but I'd like to put them in programmatically.

I'm working on a large-scale data acquisition program, and depending on what kind of routine I'm running, I'd like to put that in a page on a tab control. But the routines aren't known a priori. Ie - I might have sweep one kind of variable (eg, a magnetic field). Then at each field point sweep another variable, say a heater. So it's a nested loop structure. Then at each of those points I'd measure my device, say take an I-V curve. So I want one tab to show the data from the first sweep, another tab to show data from the nested sweep, and another tab to show the I-V curve data.

So I'd like that each time I add a new routine, a new tab is added to the main VI's front panel showing the appropriate data for that routine. However, I cannot find out how to add the controls to the page, or even how to add number of tabs, programmatically.

My old method involved having a separate main VI for every type of routine, but this quickly proved itself to be a mess and difficult to maintain. Especially for all the different equipment combinations in the lab. Additionally, there were getting to be too many controls for the front panel, so I just bit the bullet and designed a Test Executive suite.

I'm using LabVIEW 7.1, if that matters. Does LabVIEW 8 offer any more advantages along these lines?

[Jim Kring]

Jeff: I believe that adding/moving controls into the page of a tab is an editing operation (which means that you cannot do it while the VI is running). To do what you want requires scripting, using the "Create Contorl from Type Descriptor.vi" [sic] to create new controls or the GObj.Move method to move an existing control into the Page of the tab control (specifying the Page reference as the new owner). See the example, below:

[jeffwass]

Jeff: I believe that adding/moving controls into the page of a tab is an editing operation (which means that you cannot do it while the VI is running). To do what you want requires scripting

Ahhh, okay. I'll play around with that a bit, haven't done much GUI-based scripting like this yet. BTW, do you think my idea of displays in a tab control on the master VI sounds like a reasonable thing? The routine VI would basically have a reference to the appropriate display indicator on one page of the tab control on the main VI, and then update it. It looks like datasockets might have been designed to do this sort of thing, but I haven't found any good documentation on datasockets.

[Jim Kring]

Ahhh, okay. I'll play around with that a bit, haven't done much GUI-based scripting like this yet. BTW, do you think my idea of displays in a tab control on the master VI sounds like a reasonable thing? The routine VI would basically have a reference to the appropriate display indicator on one page of the tab control on the main VI, and then update it. It looks like datasockets might have been designed to do this sort of thing, but I haven't found any good documentation on datasockets.

Jeff: This isn't an approach that I have tried. It might work, but I would need to see an example. On first thought, the communication seems a bit obfuscated -- I don't like datasocket much either.

I have seen people using it for dumping stuff they dont want to see on the UI

5. Garbage collector -- Use a 2 tab control, put everything in the first one that the user should not see (for example VI inputs, VI outputs ...). In the second tab put the UI controls that the user is expected to interact with. At run time make sure the second tab is selected and that the user do not see the tab control.

PJM: Thanks an interesting idea. Usually, I put the inputs and outputs of a user interface VI off-screen. Having them in a different page of a tab control would clean things up a bit. And, you would know where to find them -- when they are off-screen, you don't know if they are up/down/left/right However, the only trick part is how do you easily change to the tab that contains the input/output controls/indicators? I guess that you could double-click on a terminal, and it would hilight the control on the front panel, thus changing to the visible tab. Another option could be to have the VI programmatically hide the tabs when it starts running and make them visible again once it completes execution.

6. Show/Hide Controls -- In UIs that have CPU intesive indicators (Tables, Graphs, ect.), I have a show/hide option that I used to implement with the visible property, but I now use tabs. The added bennefit is that I can put a message or picture in the empy tab saying that the indicators have been hidden for faster execution.

Alan: I have done something similar once, but mine was for "locking" the user interface. When the VI was "locked" it displayed a tab, that contained a "password" string control and an "unlock" button. Once the user unlocked the VI, it switched back to the tab containing all of the VI's functionality.

[yonatan.tidhar]

I used it to jange the look and fill of my FP

in case i want to have difrent bit map on my fp or any ather decorations

[Michael Aivaliotis]

1. Configuration/Options Dialog -- Put configuration parameters for different categories (or aspects of the software) into different tabs. This mode of use is probably the most common.

This is the preferred usage of tabs that I would like to see. I have seen main UI windows implemented with tabs and I got to say it stinks. What it comes down to is the programmer's lack of creativity in presenting data and information to the user. Yes, let's slap a couple of extra tabs to cram some more data into an already crowded front panel. See a great example of how not to use tabs:http://forums.lavausergroup.org/index.php?...pe=post&id=1912

If the purpose of a tab control is to navigate the user through some tasks then use a tree control on the left side with revealing information on the right. Again, the underlying thread should be static properties that can be changed or manipulated. Once this is accomplished, the window is closed and forgotten.

I have seen people using it for dumping stuff they don't want to see on the UI

5. Garbage collector -- Use a 2 tab control, put everything in the first one that the user should not see (for example VI inputs, VI outputs ...). In the second tab put the UI controls that the user is expected to interact with. At run time make sure the second tab is selected and that the user do not see the tab control.

Well, cool, this can happen but I am totally against using the tab control as something outside it's intended purpose. I also find it annoying when I have to "decode" the GUI just to find some input and output controls that should be right out in the open. You don't need to hide the controls or indicators. The less editing of the code I do the better. If a panel resizing will reveal a control then they can be placed to the left of the GUI objects. Panels only resize to the right or down.

I was actually just about to ask this question in general, and after coming to LAVA User Group today, I found you happened to asked a nice segway question yesterday. So here's my question - does anybody know how to ADD controls to a tab page programmatically? I can see how to READ the controls on any page of the tabs, but I'd like to put them in programmatically.

Why are you thinking of this? Why would you want to make such a complicated GUI window? You need to analyze and find out what your lowest data object is and how it can be displayed. Then decide how multiples of these data object can be presented as a group or individually. What are their relationships and how will they be manipulated by the user. There are many directions you can go here. For example, multiple test routines can generate plots that get pushed onto a common graph. This graph would allow you to add or remove plots as needed. You might also allow the ability to spawn multiple instances of these graphing windows all pointing to selective data. Make the user interface generic enough to accept data input from various sources without forcing the user to look at only one thing at a time. This is my main beef with tabs. It allows only a limited view into the system. What is the problem with multiple windows? Why can't I see gauges and graphs and test parameters all at the same time?

[Ed Dickens]

I use them to programatically switch between different UIs. The tabs are hidden in the executable.

Application configurations options on one tab, main program controls on another, file I/O on one, usually a hidden one with stuff the user doesn't need. It varies from app to app.

I'm creating a new application for a test station right now that I will use two Tab controls on. The test stand has two separate, but identical test stations in it and they want to be able to be running test independently from each other. So I'll divide the panel using two tab controls. I thought of using the splitter, but I don't want to have to cram everything onto a single panel and it needs a password protected "supervisor" screen to setup test limits and script new tests. Tabs work good for that.

Ed

[jeffwass]

Why are you thinking of this? Why would you want to make such a complicated GUI window? You need to analyze and find out what your lowest data object is and how it can be displayed. Then decide how multiples of these data object can be presented as a group or individually. What are their relationships and how will they be manipulated by the user. There are many directions you can go here. For example, multiple test routines can generate plots that get pushed onto a common graph. This graph would allow you to add or remove plots as needed. You might also allow the ability to spawn multiple instances of these graphing windows all pointing to selective data. Make the user interface generic enough to accept data input from various sources without forcing the user to look at only one thing at a time. This is my main beef with tabs. It allows only a limited view into the system. What is the problem with multiple windows? Why can't I see gauges and graphs and test parameters all at the same time?

The thing is I'd like to be able to display the raw data at any level of a bunch of nested routines. How do you typically do this? I wanted everything to be available from the main window, previously I'd have to go and find the subVI executing and open that to look at the graph on it's front panel, for example. So when I've got several nested routines, this gets annoying, so I figured a tab control can display the data for the various routines. And since the subroutines, especially the type of data (graph or scalar, or even 2-D intensity graph), so I figured I can put the appropriate indicators onto a tab control.

[Nico]

I use tab control in a project, and I like it because it allows us to have a simple interface.

I'd like to know how to get and set the active page of the tab control. I spent few time on this topic, but I found nothing. I searched in property node: nothing... The only way that work is to used an user event with "tabCtrl.ValueChange" but that's not what I want.

Have you some ideas to do this?

[Yair]

I use tab control in a project, and I like it because it allows us to have a simple interface.

I'd like to know how to get and set the active page of the tab control. I spent few time on this topic, but I found nothing. I searched in property node: nothing... The only way that work is to used an user event with "tabCtrl.ValueChange" but that's not what I want.

Have you some ideas to do this?

A tab is simply a numeric control which appears as a terminal in your diagram. Create a local variable of it and you can wire any one of the pages into it.

[Neville D]

The thing is I'd like to be able to display the raw data at any level of a bunch of nested routines. How do you typically do this? I wanted everything to be available from the main window, previously I'd have to go and find the subVI executing and open that to look at the graph on it's front panel, for example. So when I've got several nested routines, this gets annoying, so I figured a tab control can display the data for the various routines. And since the subroutines, especially the type of data (graph or scalar, or even 2-D intensity graph), so I figured I can put the appropriate indicators onto a tab control.

Why don't you make a subpanel of your subVI and display it on one of the tab sheets. That way you can display the front panel of the vi you are running with a much simpler UI. This would be a quick and dirty way to do it.

Another way is to develop an architecture so that data can be moved from the acquisition loop to the UI loop for display.

Then it is just a matter of selecting what you want to display.

Neville.

[jeffwass]

Another way is to develop an architecture so that data can be moved from the acquisition loop to the UI loop for display.

This is the way I'd like to do it, I don't like working with the subpanels.

THe thing is the data types, amount of data, etc, will be variable and depends on the subroutine running. So sometimes I'd want to display an XY graph, sometimes strings, sometimes an array of floats, etc.

But what would be a decent architectural way of moving data to the FP of ther other VI? Since the datatypes are always changing, maybe it is desirable to use the subpanels ,though. But when you say move the data to the UI, what are the best ways for doing this? I figured I could send some references to the acquisition program, and send raw data to the UI that way, not sure if this is the best way.

BTW - does anybody else think that the LabVIEW manuals tend to be pretty bad for describing functionality? Ie, I don't have any idea what the Data Sockets do or how to use them, and I also find their descriptions of thigns that could be useful like the TDM and INI files to be pretty bad too.

[Neville D]

But what would be a decent architectural way of moving data to the FP of ther other VI? Since the datatypes are always changing, maybe it is desirable to use the subpanels ,though. But when you say move the data to the UI, what are the best ways for doing this? I figured I could send some references to the acquisition program, and send raw data to the UI that way, not sure if this is the best way.

BTW - does anybody else think that the LabVIEW manuals tend to be pretty bad for describing functionality? Ie, I don't have any idea what the Data Sockets do or how to use them, and I also find their descriptions of thigns that could be useful like the TDM and INI files to be pretty bad too.

There are a number of ways to get data from a daq loop to the UI:

1 An LV2-style (functional) global.

2 Using a Q to write data from the DAQ loop to the UI loop.

Take a look at the various Design patterns under New>Design Patterns.

Yes Datasocket documentation should be cleaned up a bit.

Datasockets are a way to communicate with a LabVIEW program on a different machine across a network (intranet or internet), without having to develop your TCP/IP communications from scratch. You can get up and running very quickly with it, but it does have a few quirks.

Neville.

[JPrevost]

This is the preferred usage of tabs that I would like to see. I have seen main UI windows implemented with tabs and I got to say it stinks. What it comes down to is the programmer's lack of creativity in presenting data and information to the user. Yes, let's slap a couple of extra tabs to cram some more data into an already crowded front panel. See a great example of how not to use tabs:http://forums.lavausergroup.org/index.php?...pe=post&id=1912

If the purpose of a tab control is to navigate the user through some tasks then use a tree control on the left side with revealing information on the right. Again, the underlying thread should be static properties that can be changed or manipulated. Once this is accomplished, the window is closed and forgotten.

That is mighty speculatory. Sure my program isn't perfect but to say this is how not to use tabs is wrong. Just curious, how would you change my program to not use tabs? I also resent the comment about it coming down to the programmer's lack of creativity... that is also false. Sometimes the easiest way for a user to navigate a main program is to see all of their options at the top in a nice orderly fashion. Having beta tested my program already the only comment that was issued about the GUI was the cluttered main tab. They wanted more tabs . I am, when time allows, going to move the configure tab to it's own seperate vi. Other than that, nothing is changing unless you can give me a good reason why it should. My program is not to be navigated in order. There is a lot of data to process so I've dispatched it with tabs to keep things organized. You might also want to see what is in the other tabs before you use my program as a "how not too" example.

[Michael Aivaliotis]

This is the way I'd like to do it, I don't like working with the subpanels.

THe thing is the data types, amount of data, etc, will be variable and depends on the subroutine running. So sometimes I'd want to display an XY graph, sometimes strings, sometimes an array of floats, etc. But what would be a decent architectural way of moving data to the FP of ther other VI? Since the datatypes are always changing, maybe it is desirable to use the subpanels ,though. But when you say move the data to the UI, what are the best ways for doing this? I figured I could send some references to the acquisition program, and send raw data to the UI that way, not sure if this is the best way.

Yes, well what you want is to isolate the main GUI from knowing or even caring about the representation requirements of the test routine. One way to do this is to build a framework into the main GUI that calls various methods of the routines. This is where GOOP helps. For example, you would make each test routine a class that has several methods. One of the methods would be "run test", and another coould be "display data". When you call the "display data" method, you would pass it a reference to a location that you want the data to be displayed. The location would be an embeded panel. Now, the GUI doesn't care how the data will be displayed. All it knows is that data will appear in this embeded panel. You can really do some powerfull stuff with this. For example you could call the "display data" method multiple times. Each call would create a new instance of the data display object. This would allow, for example, multiple views into the same data (one graph zoomed, another expanded).

You may ask the question. So how is the data displayed. Well, this is the exclusive responsibility of the class. It has knowledge of the data and would have a VI panel dedicated to this. This could be a seperate VI or handled within the same test routine. Now, you could even go one step further and make the "data display" a class. Then you could make it generic enough to handle your data. Your test routines would call this class and pass them the GUI reference. Let's face it, how may data types do you have? Graph, Boolean, String, Numeric. If it can handle those then you're golden.

Also, don't lock yourself into the very limiting "Main Window" concept. With the approach mentioned, you can have multiple windows, each displaying a different piece of data. Your customers will love you for this.

[gleichman]

That is mighty speculatory. Sure my program isn't perfect but to say this is how not to use tabs is wrong.

I would have to agree with Jon. I don't think the main problem with his UI is the tabs. (Please don't take this personally) This UI suffers from an apparent lack of organization and an over use of clever controls. I would suggest taking a look at some past NI Week presentations of "The Good, The Bad, and The Ugly" by Greg M. NI's web site is being updated at the moment, so I can't provide a direct link.

[jeffwass]

There are a number of ways to get data from a daq loop to the UI:

1 An LV2-style (functional) global.

2 Using a Q to write data from the DAQ loop to the UI loop.

Take a look at the various Design patterns under New>Design Patterns.

Yes Datasocket documentation should be cleaned up a bit.

Okay, I'm already using those methods, I actually implemented a GOOPish kind of LV2 that maintains an array of 'object' references, which can take a variety of commands. I also use the producer/consumer type model, but with TWO consumer queues, one where FP commands pop onto the main acquisition-processing queue, and another queue in which any subroutine can pop commands to update the main GUI display.

That works pretty well so far for things like the list of instruments, a tree for list of routines with some config data, but haven't gotten the actual acquired-data visualization stuff worked out yet.

[JPrevost]

I would have to agree with Jon. I don't think the main problem with his UI is the tabs. (Please don't take this personally) This UI suffers from an apparent lack of organization and an over use of clever controls. I would suggest taking a look at some past NI Week presentations of "The Good, The Bad, and The Ugly" by Greg M. NI's web site is being updated at the moment, so I can't provide a direct link.

I took a look at those presentations but only briefly as this programming isn't my "job" per say. I'll take a closer look and see if I can't get some tips and direction. As for an apparent lack of organization, apparent would be the key word. Believe it or not (seems like not around here) my program is very organized. Each tab has processes information that another tab does but at the same time is specialized. Example; The VE fuel needs RPM, MAP, and BLM averaged. The main HUD shows RPM, MAP, and BLM but the BLM is instantanious! This is why I used tabs. There is a lot of redundancies and I needed it to be easy for the user to go back and forth between tabs without a lot of clicking.

I'm no expert but aren't tabs suposed to be a form of organization? If that's not what I'm doing then I'm obviously in the wrong place. My code uses the tab displayed to case out the terminals that don't need updating. As in, switch away from that "busy" front tab to a different tab and the front tab gauges don't get updated. What's that called, a state machine? It's in a loop .

[gleichman]

I took a look at those presentations but only briefly as this programming isn't my "job" per say. I'll take a closer look and see if I can't get some tips and direction. As for an apparent lack of organization, apparent would be the key word. Believe it or not (seems like not around here) my program is very organized. Each tab has processes information that another tab does but at the same time is specialized. Example; The VE fuel needs RPM, MAP, and BLM averaged. The main HUD shows RPM, MAP, and BLM but the BLM is instantanious! This is why I used tabs. There is a lot of redundancies and I needed it to be easy for the user to go back and forth between tabs without a lot of clicking.

I'm no expert but aren't tabs suposed to be a form of organization? If that's not what I'm doing then I'm obviously in the wrong place. My code uses the tab displayed to case out the terminals that don't need updating. As in, switch away from that "busy" front tab to a different tab and the front tab gauges don't get updated. What's that called, a state machine? It's in a loop .

When I said that the UI suffered from an apparent lack of organization, I was (as I stated in my post) NOT referring to your use of the tab control. I did not go into detail because it was off topic.

[OT] Problems with the UI and ways to improve it, IMHO.

1. The group of LED indicators appear organized, but everything else seems sandwiched together (placed wherever they fit). Use smaller (less graphical) indicators and group them logically with clusters or decorations. Leave white space between groups.

2. Controls are at unexpected places. For example the "STOP" button (probably an important thing) is hidden in the middle of your panel among many attention grabbing indicators. Other controls are dangling in and out of the tab control and some have no labels.

A good UI makes your software easier to use by others (less support required!). Here is an example of how I used a tab control interface. The first tab is a summary and the other tabs show detailed information for each DUT.

[JPrevost]

gleichman, I like your program, very easy to read but it also doesn't look like it would fit on an 800x600 resolution display. That was my problem. Before I decided to support low-po laptops I had lots of room, then I had to dumb it down which makes it look like there is no organization to my program. Look again and you'll see that there is a lot of organization considering what is being displayed. The intake air temp and engine coolant temp are grouped together in the bottom left, the speed and rpm are just above that, just like how your actual gauge cluster in the car is grouped. Then there are the flags in the upper right which are organized by color and grouped occording to other considerations (digital in/outs, oxygen sensor dependent, etc.).

My stop button has been moved to the upper left hand corner and all of the buttons are self explanitory. Tool tips are everywhere and documentation is extensive. This program was ment to be easy to use when in a vehicle. The BLM's go from low to high with 128 being the mid and the background colors change to indicate without having to look at the actual number... all a little cluttered but with only a couple uses the users liked my organization. Tuning a complicated dynamic mechanical/chemical system is one thing, doing it real-time is another, helping people do it themselves is even harder, documenting, auto-learning calibrations through closed loops, etc. make it darn nere impossible to do with 1 programmer. That's why I took offense to my program being used as a do not example. If you spent a lot of time testing (over a year) would you like it if somebody came in and said, this is how not to do it without taking a closer look?

[are_hm]

On 16/1/2006 at 9:39, Ed Dickens said:

Los usos para cambiar programáticamente entre diferentes IU. Las pestañas están ocultas en el ejecutable.

Opciones de configuración de la aplicación en una pestaña, controles del programa principal en otra, E / S de archivo en una, normalmente una oculta con cosas que el usuario no necesita. Varía de una aplicación a otra.

 

Estoy creando una nueva aplicación para una estación de prueba ahora que usaré dos controles Tab. El banco de pruebas tiene dos estaciones de prueba separadas, pero idénticas, y desean poder ejecutar la prueba específica una de la otra. Entonces dividiré el panel usando dos controles de pestañas. Pensé en usar el divisor, pero no quiero tener que agrupar todo en un solo panel y necesita una pantalla de "supervisor" protegida por contraseña para configurar los límites de prueba y escribir nuevas pruebas.Las pestañas funcionan bien para eso.

Ed

Hola me gustaría saber como hizo para que todas sus pestañas simule al momento de dar run en su programa puesto que tengo ese problema en el mio y solo me simula una pestaña al dar run tengo un event structure y En su entrada puse el tab, no me simula ni así ni de otras forma, le agradeceria que me ayude porfavor.