Resource usage for inactive tabs on a Tab control

[Christian Butcher]

This is almost certainly a case of premature optimization, but in the interests of learning something useful:

If I create a front panel containing a tab control, and each tab has some controls or indicators on it (or a subpanel, perhaps...), what is the runtime cost associated with the inactive tabs?
If I insert a subVI as a subpanel, should I remove the vi when the tab is not active, or will LabVIEW's clever handling of inactive parts of a front panel extend to this?

[Neil Pate]

Not directly answering your question but I would say the biggest favour you can do yourself is not use tabs, subpanels are your friend here.,

To answer your question, I know that in the past LabVIEW's "cleverness" sometimes caused bugs with charts where data would just not be present on the indicator if was not visible, but I would not bother about unloading panels.

[smithd]

7 hours ago, Christian Butcher said:

If I create a front panel containing a tab control, and each tab has some controls or indicators on it (or a subpanel, perhaps...), what is the runtime cost associated with the inactive tabs?

If I had to guess, it still has to do all the work with copying data into the control (so you're still inserting into a rolling buffer for graphs, still copying big arrays for charts) but you save time by not having it redraw. For big data like charts, you can check the state of the tab control before writing and I have seen that help in big code.

4 hours ago, Neil Pate said:

Not directly answering your question but I would say the biggest favour you can do yourself is not use tabs, subpanels are your friend here.,

I dont know if you are looking at some specific thing he said elsewhere, but in general I disagree. If you know what you want to put on the screen, there is nothing wrong with tabs and subpanels overcomplicate the situation because you've gone from 1 UI loop to N.

[Neil Pate]

26 minutes ago, smithd said:

I dont know if you are looking at some specific thing he said elsewhere, but in general I disagree. If you know what you want to put on the screen, there is nothing wrong with tabs and subpanels overcomplicate the situation because you've gone from 1 UI loop to N.

Nope, just guessing. Something with two tabs very often ends up as ten tabs with a single event structure handling dozens if not hundreds of value change events. More than one UI loop is good, not bad.

You may know what you want on the screen today...

 

Edited October 20, 2016 by Neil Pate

[Christian Butcher]

 

Perhaps my problem is that the solution I've envisaged is so unwise that more experienced developers like yourselves can't imagine what I meant (or maybe, can imagine but immediately discard the idea as stupid and assume I meant something else...)

My starting idea was to contain as the bulk of my main FP a Tab Control, with around 5 tabs. The default tab might contain a graph, a second tab might contain a subpanel to a settings configuration VI (this would in my imaginary implementation send messages on value changes within it's own embedded front panel to the main VI/controller), a third tab might contain some series of indicators describing the system status, and so on. I chose a Tab Control on the basis that this was the control meant to handle a set of controls/indicators which were grouped, but where I didn't need simultaneous access/views of multiple groups.

I suppose one possible variation might be to have a tab control (or custom control that looked like a tab control) and then just one subpanel drawn over the top of it, and switch the subpanel's contents based on the value of the tab control (/ series of buttons with some decorations making them look like tabs). I already have some VIs which implemented a subpanel with contents controlled by a menu ring, so it shouldn't be hard to apply the same idea to my UI (he said, having not tried it)

10 hours ago, smithd said:

If I had to guess, it still has to do all the work with copying data into the control (so you're still inserting into a rolling buffer for graphs, still copying big arrays for charts) but you save time by not having it redraw. For big data like charts, you can check the state of the tab control before writing and I have seen that help in big code.

Thanks for the tip. The cost you describe is basically what I imagined seemed reasonable, but I'm glad to have it confirmed (since I'm not certain I could easily test it conclusively)

9 hours ago, Neil Pate said:

You may know what you want on the screen today...

So true...

 

 

[Neil Pate]

Christian, the original solution you have described is very common, I have definitely used it in the past, with good success. Such an implementation certainly will allow you to get up and running nice and quickly. Unless you are updating your indicators at a ludicrous rate (like > 1000 Hz) or throwing huge graphs onto the screen I would not worry about performance. Modern CPUs are just so good. Even today I still use a tab for a GUI which I know is going to be simple (like a pop-up window or something), but certainly never as my top-level.

However, the problem with the tab structure is only good for logical GUI grouping, it does not help you at all on the block diagram which is where all the trouble will be. I guarantee you, if your application works well and has a predicted lifespan of more than a few years you will get more and more requests just to add another button or indicator. This will be easy at first but after point you will reach critical mass of controls and indicators where it just becomes too unwieldy for you as a developer to make changes. You will struggle much more than the compiler... 

If you are comfortable with the idea of a subpanel for your configuration, then yes I would take it one step further and replace your tab with a subpanel. This architecture forms the basis of most of my GUI type applications to this day. Also I probably would not use a subpanel for the config, how likely are you to want to swap that out "on-the-fly" without changing the rest of the GUI?

Note that as smithd mentioned, if you do go down the subpanel route you will have multiple VIs running in parallel, so you will need to start thinking about how you will communicate between them. There are lots of different techniques (queues, user events etc), figuring out this is a great way to push your LabVIEW skills to the next level.

Edited October 21, 2016 by Neil Pate

[Christian Butcher]

43 minutes ago, Neil Pate said:

However, the problem with the tab structure is only good for logical GUI grouping, it does not help you at all on the block diagram which is where all the trouble will be. I guarantee you, if your application works well and has a predicted lifespan of more than a few years you will get more and more requests just to add another button or indicator. 

I see the problem - for each control or indicator, I get a new terminal on my BD which I have to place somewhere, and wire appropriately, handling in a case and so on. By moving these into subVI's embedded (whilst needed) in subpanels, I delegate handling of the controls/indicators to the VIs that have some interest in the controls, rather than having a spaghetti mess looming in the future on my GUI's BD.

43 minutes ago, Neil Pate said:

If you are comfortable with the idea of a subpanel for your configuration, then yes I would take it one step further and replace your tab with a subpanel. This architecture forms the basis of most of my GUI type applications to this day. Also I probably would not use a subpanel for the config, how likely are you to want to swap that out "on-the-fly" without changing the rest of the GUI?

I thought about using a subpanel for config based on something I read here written by Hoovaah (spelling? :s) about his method to register different modules' settings pages. So whilst the collection of settings a module needs probably won't change (much..., and at least not in general) the collection of modules/actors that are running might. By having a subpanel, I can use some sort of selection (I've previously implemented an array of buttons - it wasn't great but it worked. Some thought needed for a better idea here maybe) to choose which module's settings to edit. 

43 minutes ago, Neil Pate said:

Note that as smithd mentioned, if you do go down the subpanel route you will have multiple VIs running in parallel, so you will need to start thinking about how you will communicate between them. There are lots of different techniques (queues, user events etc), figuring out this is a great way to push your LabVIEW skills to the next level.

I think I should have this covered with the Actor Framework I'm using (based on the version that ships with LabVIEW, i.e. AQ's framework, I think). Still takes me some thought to work out who is responsible for sending messages where, but I'm catching on. Another week or so and I should have it down. (Previously I used QMH based on the Continuous Measurement and Logging example project)

[Neil Pate]

Sounds like you are on the right track. I do like your idea of a subpanel based config page, but in all honesty have not ever actually needed one yet (and I am talking reasonable sized projects here).

I personally am not a big fan of the Actor Framework that ships with LV. I have probably not given it enough of a chance, but it just feels too busy for me. I have created my own lightweight Actor Framework (based on User Events and not queues) and that does not use the command pattern (I don't really like having a class per action/message).

[ShaunR]

4 hours ago, Neil Pate said:

However, the problem with the tab structure is only good for logical GUI grouping, it does not help you at all on the block diagram which is where all the trouble will be. I guarantee you, if your application works well and has a predicted lifespan of more than a few years you will get more and more requests just to add another button or indicator. This will be easy at first but after point you will reach critical mass of controls and indicators where it just becomes too unwieldy for you as a developer to make changes. You will struggle much more than the compiler.

While true, it is fairly easy to mitigate using property nodes to handle groups of controls. The main reason I refuse to use tab controls is because of the difficulties with control scaling and positioning - especially with splitters on the FP and tab itself. Otherwise I have no particular problem with them.

Edited October 21, 2016 by ShaunR

[Christian Butcher]

Ah, seems I failed to manage to get this site to post my reply again.

I found that a tab control with minimal (5px) width (it's vertical) next to a decoration covered by a subplot allows me to use a nice looking tab control (your opinions may vary) for choices without having to actually use a tab control.

Probably it's more expensive than a menu ring (no evidence but seems plausible to me) but I doubt it's hugely so and I quite like the interface.

Meanwhile, I can take onboard suggestions about using subplots to improve scalability since I only have one 'panel' rather than an actual tab control 

[hooovahh]

In regards to tabs, there is an idea exchange item to have them fit to pane which I think would be very helpful.

https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Fit-to-pane-Fit-to-tab/idi-p/932452

Aside from that I have come up with a solution, where there ware two tabs, in two panes.  The bottom tab has no control, and is just changed when the top tab value changes.  Then I hide everything on the top tab, other than the tab controls, and the bottom tab I had the tab controls but leave the tab content.  This allows for the objects in the tab to fit to pane, and resize as you would expect.  In this tab you can still have a subpanel that fits to the pane, or graph, chart table, or whatever.  It is just another example of UI work arounds in LabVIEW to make a good UX.

[Neil Pate]

You have my respect. I gave up on resizing GUIs in LabVIEW about a decade ago...

Christian, I usually customise a boolean radio control to have nice big buttons vertically, this drives the selection of the current "view" which is just what I call the VI (actor, module, whatever) running in the subpanel.

On the left hand side is the customised radio button. In the middle is the subpanel and down at the bottom (the yellow bar) is where my status panel (also a subpanel) gets loaded.

Edited October 22, 2016 by Neil Pate

[smithd]

Isn't the radio button approach still static? I'd think you would at least use a listbox so you could easily add tabs. 

For our configuration editor we used a tree control and subpanel (http://www.ni.com/example/51881/en/) with a sample implementation shown on this page (https://decibel.ni.com/content/docs/DOC-47483 , 3rd image).

Might be a bit complicated for simple editors, but to my mind thats what the tab control is for.

[Christian Butcher]

13 hours ago, Neil Pate said:

Christian, I usually customise a boolean radio control to have nice big buttons vertically, this drives the selection of the current "view" which is just what I call the VI (actor, module, whatever) running in the subpanel.

I also tried a radio control with the 'OK Button' placed for each item and customised but couldn't rotate the boolean text, and using a label was difficult(/impossible?) to keep in position. I considered custom graphics via gimp but my miserable gimp skills make this a very undesirable option and mean that changes require quite considerable extra time to implement.

That being said, your image looks perfectly nice, and so maybe I should just use slightly larger buttons and multi-line boolean text as needed, and then I can use controls for the purposes they're intended rather than having a tab control with effectively no tab panel.

 

7 hours ago, smithd said:

Isn't the radio button approach still static? I'd think you would at least use a listbox so you could easily add tabs. 

For our configuration editor we used a tree control and subpanel (http://www.ni.com/example/51881/en/) with a sample implementation shown on this page (https://decibel.ni.com/content/docs/DOC-47483 , 3rd image).

Might be a bit complicated for simple editors, but to my mind thats what the tab control is for.

Thanks for these links - I took a look at them and the example seems very much like what I imagined reading about the listbox->subpanel arrangement described. I've not used a listbox yet, but I assume it's fairly straightforward. I'll certainly read through the article more closely when I have LabVIEW in front of me (LV is only licensed for my institution's machines, not private use as far as I know) and consider this implementation for the settings 'tab' (which is unlikely to be a tab anymore, but rather a subpanel-embedded VI (I'd guess the 'Actor Core' for a 'Settings Manager' actor, or similar)).

 

[Neil Pate]

19 hours ago, smithd said:

Isn't the radio button approach still static? I

Absolutely. My top-level main GUIs are entirely static with regards to what "views" can be loaded into the main subpanel. I can only shudder to think how complicated this would all get if everything (including every single scrap of business logic) was "templated".

[hooovahh]

I've absolutely done the list box approach.  Similar UI as you where the listbox is on the left and populated at run time, then the subpanel can be loaded in the main UI.  Each of these subpanels VIs can be poped out and pinned too, but that's only done during debugging so you can look at two manual panels at the same time and see how changing one effects another.  Another good example of this type of UI is the configuration dialog, which is seen in the Tools >> Options dialog in LabVIEW.  All of these are more modular approaches than a static tab control, but I don't think this answers the original question.