Tab Control Management

[SDuffyLV]

Hi All,

Is there a more efficient way to perform the attached VI?

Simply, it's push buttons to control tabs within tabs. For this quantity of tabs, this is fine.

Now, imagine there are a lot more than just the 3x2 tabs that are in this VI. How would this be managed better?

If you need anymore information let me know!

[GerdW · Accepted solution]

Hi SDuffy,

---

@SDuffyLV wrote:

Simply, it's push buttons to control tabs within tabs. For this quantity of tabs, this is fine.

Now, imagine there are a lot more than just the 3x2 tabs that are in this VI. How would this be managed better?

---

It's not even "fine" for this amount of tabs and buttons!

Why do you even need 3 pages with a 2-page tab in each of those pages?

You should start by implementing a better UI than to improve the tab handling (IMHO)…

• Why do you even need 5 event cases to handle all the tabs? You could do this all in one event case!
• Why do you need so many local variables?
• Why do you need an additional wait function in the loop? Right now it's just pointless, and there still is a timeout event case you could use instead. But even that timeout event is pointless right now…
• Why do you use individual buttons when you implement the behaviour of radiobuttons in your code? Simply use radiobuttons!
• Why is there no event case for your stop button?

See this (kind of dirty) implementation using 2 radiobuttons:

(Uhh, the snippet is hiding coercion dots!?)

[RTSLVU · Accepted solution]

You need to learn how to use RADIO BUTTONS!

Properly label your tabs and a simple Event Structure is all you need to change them.

I often get asked why use buttons to control a Tab Control... Well since tabs are like totally 90's GUI design, I like to make "invisible" tabs and have buttons to press to select what tab is displayed. This makes it look like there are no "tabs" but the entire screen is changing instead. 

[altenbach]

A tab (by default) is a control and should be used as such. You are doing the "tail wagging the dog" thing by making it an indicator and setting it externally. In 99.9% of all programs out there people are used to click on the tabs directly to change the view, so why do things backwards?

Can you explain the usage scenario where this makes sense?

And, as others have already said, your code is overly complicated and convoluted. Way too much duplicate code, completely unnecessary code, and way too many local variables. Also, why is there a timeout case? Why is there a 1ms wait in parallel to the event structure?

[altenbach · Accepted solution]

Here's what I might do.

• One event case for everything.
• No local variables (once no longer in development).
• Lots of coercion dots, but not a problem here.

[SDuffyLV]

Thank you all for the replies.

I didn't realise when making this post that this would be an important bit of information but none of these codes work on the Real-Time Module of LabVIEW.

The codes do work with base LabVIEW, however.

Is this functionality possible with the Real-Time Module? I'm assuming that Reg Events have to be used for this and am currently trying to figure this out.

[SDuffyLV]

I appreciate the feedback. I understand this has not been a well thought out code, it was just to get the concept across.

1) We don't need 5 cases, you're right

2) I've picked up a bad habit of placing indicators/controls outside of any loops so that they're easily visible in large programs

3) I don't, that was just a stupid mistake

4) I was not aware of the functionality of Radio Buttons, this is a revelation!

5) The Stop button was missed out because it wasn't the main focus of the code, that was laziness on my half, apologies for that.

[FireFist-Redhawk]

---

@SDuffyLV wrote:

Now, imagine there are a lot more than just the 3x2 tabs that are in this VI. How would this be managed better?

---

To answer this question, you probably want to break out the functionality so that you have multiple SubVIs that you can call, each with their own user interface. Any more specificity would require some more information about what it is you're trying to accomplish. There's subpanels, custom runtime menus, all sorts of ways to manage that better.

[altenbach]

---

@SDuffyLV wrote:

Is this functionality possible with the Real-Time Module?

---

The realtime module typically does not have a front panel, so please explain why you are shuffling around UI elements. (see also).

Maybe you should take a few steps back and tell us what you are trying to do, not how you are trying to do it.

[GerdW]

Hi SDuffy,

---

@SDuffyLV wrote:

I didn't realise when making this post that this would be an important bit of information but none of these codes work on the Real-Time Module of LabVIEW.

---

Well, that is an important information about that whole problem…

You should learn to write better questions!

Which RT target do you use? You know most of them don't support UIs at all because they don't support monitors/displays?