LabVIEW tab control not working

[Vwilks14]

I am using LabVIEW to operate an ESPEC environmental chamber. In my front panel portion of the program I used multiple tabs due to the amount of graphs and input data the program has. When I run the program hooked up to the system it will not let me switch between tabs. The program runs and I can flip through the tabs to see the data recorded by the graphs once I hit stop. Does anyone know how to fix this? Do tabs not operate fully when a program is running? 

[aputman]

Please share your code.  It sounds like you have a long running loop inside of an event structure.  And the event is locking out the front panel updates until you click stop and the loop exits.  If so, this is very bad design.

[Vwilks14]

The code is very long, do you know off-hand which type of long running loop would cause this? Or is this the case for all running loops inside an event structure

[aputman]

All long running loops inside of event structures is bad design.  Look for examples of state machines.  State machines use a very simple messaging system.  "When a button is clicked, go to the indicated state and execute the code there."  Depending on the code architecture, the long running code could either be in a loop separate from the one with the event structure or it can be in the same loop with the event structure (in which case, you have to be careful again to not lock out your front panel event structure).  

An example of the first option might be the template for a producer/consumer design pattern for events that ships with Labview.  An example of the second option is the JKI State Machine, a very good design that I use regularly.  This can be found on VIPM.

[aputman]

Oh....and by "long running loops", I mean longer than 1sec.  The reason for it is because I like for my UI to respond quickly, meaning that when I press the button, I want it to do what it's supposed to do right when I tell it to do so.  If there is any sort of delay, the user starts randomly clicking buttons thinking the UI is locked when in fact all of those events are being queued and when they are allowed to execute, pandemonium sets in, windows start popping up, etc.  

[altenbach · Accepted solution]

Is it possible that your tabs are indicators instead of controls? Unless they are controls, you will not be able to operate them at run time. (you can switch mode by right-clicking).

[billko]

---

@aputman wrote:

Oh....and by "long running loops", I mean longer than 1sec.  The reason for it is because I like for my UI to respond quickly, meaning that when I press the button, I want it to do what it's supposed to do right when I tell it to do so.  If there is any sort of delay, the user starts randomly clicking buttons thinking the UI is locked when in fact all of those events are being queued and when they are allowed to execute, pandemonium sets in, windows start popping up, etc.  

---

LOL - Call this syndrome the "Karen click-fest" after my wife, who is the impatient sort who will do exactly what you just described, then wonder what the heck just happened, when all those clicks come due.

Sometimes the UI gets ahead of the code.  By that, I mean that since the UI and the code are largely decoupled in my applications, the UI remains ultra-responsive, but stuff may still be happening under the hood.  If I feel that the execution time can take longer than the amount of time it would take a user to move the mouse and click a button, I will throw up a busy icon to prevent the user from clicking anything until the application is ready for input.  If the user might need to click on some kind of abort button, I have no choice but to disable all inputs individually for the duration of the long-running code, except for the "eject the warp core" button.

[cbutcher]

---

billko wrote: 

If the user might need to click on some kind of abort button, I have no choice but to disable all inputs individually for the duration of the long-running code, except for the "eject the warp core" button.

---

I saw someone describe some time ago the idea of placing a transparent decoration over your VI to block key-presses. Perhaps you could, by combination of multiple decorations if needed, mask your buttons to disable and leave the Abort button uncovered, allowing you to only use one (or a small number) of references to property nodes rather than having to iterate through all but one control?

[billko]

---

@cbutcher wrote:

---

billko wrote: 

If the user might need to click on some kind of abort button, I have no choice but to disable all inputs individually for the duration of the long-running code, except for the "eject the warp core" button.

---

I saw someone describe some time ago the idea of placing a transparent decoration over your VI to block key-presses. Perhaps you could, by combination of multiple decorations if needed, mask your buttons to disable and leave the Abort button uncovered, allowing you to only use one (or a small number) of references to property nodes rather than having to iterate through all but one control?

---

That would be okay for most applications.  Of course the caveat would be that overlapping controls and decorations put a strain on the computer, since I don't believe that LabVIEW features accelerated graphics (although I haven't looked into NXG, which I would assume probably does, because it's the only way I can see it doing certain tricks).

[MacGeezer]

How I turned the Tab control into an indicator, I'll never know. Thanks!