operating single row scroll tabs

[Wolfgang]

Hello,

let me say first that I am not an expert with tab panels, I use them and am happy that they do what I want them to do - until I discovered the following issue. My question is if the described behavior is expected to be like that, or if I missed some configuration setting.

As you can see below, I have several tabs and selected the option 'single row scroll tabs' because I have too many tabs for the restricted panel space available.

Accordingly, in the upper right corner there are two triangles, pointing to the right and to the left, meant to move the tab panels using the mouse.

It is also possible to use the keyboard to select tabs, using the left/right arrow keys to move between tabs.

Now, my surprise, mouse operation and keyboard operation are not equivalent.

For this I have prepared three screenshots:

The first shows the selected, active tab - all is fine:

The second shows the situation when I use the right arrow key on the keyboard, both the tab and the tab panel move - as expected.

But, if I start from picture I and use the mouse instead, only the tab moves, the tab panel remains in place. This, to me, looks very irritating and I would expect a bug, but who knows, see my comments above.

In any case, as usual, I would be grateful for comments. I am using CVI 2020f1.

[RobertoBozzolo]

I never noticed such a behavior but it is to be said that I honestly hate the single-row-scroll aspect so I never use it 😉Nevertheless I am using Code Blocks IDE for some projects we have on Linux and the build options window in that IDE actually uses a single-row-scroll tab: I can say that the behavior in that product is consistent, i.e. operating with the keyboard and the mouse both have the effect of changing the active tab and updating the tab page accordingly.

I would be stumbled as well by the behavior you mention of CVI tab control!

[Wolfgang]

Thanks Roberto for your feedback 😀

Let's see what the feedback from NI will be on this unexpected/strange behavior.

O.k. so you dislike this single row tab design, what would be your preferred alternative given some space constraints? A single row will leave only very little space for the tabs, so one could label them with I, II, III only, but not with a more detailed description. Multiple rows on the other hand will take a significant fraction of the tab panel, leaving less room for controls.

The alternative I could think of would be showing only one 'tab' / hiding all the other mini-panels using a ring control or menu items, but for me cycling through these panels seems much simpler with tabpanels than via a menu bar or an additional ring control...

[RobertoBozzolo]

Wolfgang, I cannot answer directly to your question: on one side I am very rarely in conditions where 20 pixels of screen real estate make a big difference so that I couldn't use multiline tabs; on the other hand I tend to avoid complex UI to ease up operator's life. So the best answer I can give you is that I would rethink the application to obtain a simpler panel, but I don't know if it makes sense in your case.

I can say I would try to avoid that pattern as much as possible: I personally judge those tab controls cumbersome, very slow in handling and too hard to understand and I always feel I missed something on non-visible pages so I wouldn't deploy an application just to have my customers complain they have lost some detail...

But this is only my personal feeling, I don't pretend this to be a rule or even to be agreed to by anybody else 😉

[Wolfgang]

Thanks Roberto for sharing your personal feelings 😁

I would always agree with simplifying UI design, but in this case (so far) I do not see any better alternative.

[Wolfgang]

I do not know if it may be of any help/interest but I just found out that building an executable is not required to reproduce the issue - having the UIR file in the UI editor and pressing the Operate Tool button does show the same strange effect. This at least excludes my code as the reason for the malfunction 😊

[RobertoBozzolo]

This could be a good new!

If I'm not wrong, it means that the control behavior is handled by the RTE and not by the compiled executable. It implies that if an update is implemented in future releases of the RTE it may be inherited also by programs compiled in older IDEs simply updating the run-time on the target machine without need to recompile the exe.

I don't remember now an actual example, but I already noted similar situations in the past where an annoying bug was solved by updating only the RTE.

[Wolfgang]

This issue has been confirmed to be a bug and has been assigned the CAR number 1449107