LabVIEW
UI bugs(?) when Tab control partially covers other controls and indicators
Solved!
Hi,
I'm running into some strange graphical artifacts in my application when using Tab controls on LabVIEW 21.0.1f2 (64-bit) running on Windows 11.
What I'm trying to do is have the tab of a Tab control partially overlap other controls and indicators, like a Chart, for example so that when you click on the tab, the Tab control is repositioned so that it reveals whatever is inside it, blocking more of the Chart.
While partially covering the Chart, the tab is completely drawn over and dissappears everytime the Chart is updated. But when "open", in which case the Tab control is fully visible, this doesn't happen at all, even while the Chart is being updated.
Is this behavior a bug? Is there a way to fix this programmatically by manipulating a property?
A similar glitch, in this same use case, happens when a Tab is set to Disabled and Greyed Out, with the "greyed out" visual effect covering the Chart and/or FP background as well, instead of being restricted to the area where the tab of the Tab control is.
This is annoying because it detracts from what I'm trying to accomplish in terms of the app's user experience.
I've attached an animated GIF to illustrate what's happening
Hope to get some help from the community.
Best regards,
Habil
@habsilva wrote:
But when "open", in which case the Tab control is fully visible, this doesn't happen at all, even while the Chart is being updated.
What does 'when "open"' mean? The gif is quite blurry and does show the effect but not what's causing it.
I'd need to understand this to reproduce the bug (which it is, but in a corner case, so don't expect it to be fixed). A minimal VI that demonstrates the issue would help (pref. LV 20 or earlier if you want to max out the support you get).
There are definitely some shady behaviors when it comes to graphs and tab controls.
If the graph is transparent (or parts are transparent) that doesn't help...
A possible solution (that might not help at all) is to put the graph in a subpanel.
You could play a bit with defer panel updates and\or synchronize display settings of the controls.
The type of subpanel might make a difference (e.g. system or classic)
Search LabVIEW like a graph!
@habsilva wrote:The "tab being open" means that it's been repositioned so that it is almost fully inside the front panel bounds.
You can also see that the other tabs, when partially moved outside of the front panel bounds, do stay visible if at least one tab control is in the "open" state, on top of the chart.
What's the ASML overlay thing? A decoration?
It seems that's the one thing that makes it behave incorrectly.
Yet, I still can't reproduce it.
@habsilva wrote:It seems like the effect of an optimization in the LV drawing routines, that tries to detect when objects overlap, and fails to detect that a part of the tab control is on top of the chart, when it's just the tab. But does detect the overlapping if more of the tab is covering the chart.
I'd guess it's a timing issue between screen updates of the individual components. The graphics are probably (partially, for instance the graph data) updated on an offscreen bitmap, and then copied to the screen. Usually, this happens in Z-Ordering, but for whatever reason this ordering is disturbed. Maybe because there's a lot of data and it takes too long, maybe because there more than one stacked object somehow corrupts this order...
I've definitely seen it before, but I only achieve problems and solutions in my head, which uses lossy compression 🙄.
I do recall getting similar issues with a subpanel, and maybe changing the VI's transparency or the subpanel's transparency to fix it? With glitches like this, anything can cause it, and anything might solve it.
If you can dress your code down to only 'do the bug' (and post it), we can all have a go at a solutions.
@habsilva wrote:I've also tried a subVI panel and it has the same effect as the single Chart in the main VI's front panel.
Defer panels is something that I wouldn't like to do because it's not applicable to subVI panel updates, right? These would happen completely asynhronously from the GUI engine updates, which runs in the main VI in parallel with everything else.
Defer panel updates can definitely be a can of worms...
IIRC (pretty sure) a VI defers panel updates if it's turned on for it's own FP or any VI in one of it's subpanels.
They do happen when you tell it to, and that can be asynchronous from the updates. They don't have to be, as you're the one updating the data. So defer panel updates, update values, maybe move, defer panel updates off might do something. However, I doubt it. defer panel updates solves performance issues, but I've only seen it cause glitches, and don't recall it solving glitches.
The ASML "thingy" is just my wallpaper.
I'm resizing the front panel window to cause the issue to manifest and the screen grab tool is then capturing the background -- that's what you're seeing there.
I've attached a simple VI that easily reproduces the problem described.
If you click on the Reveal Panel button, the right-hand "panel" is extended on top of the chart and the Z ordering works well; when the "panel" is concealed the glitch is made apparent:
You can see that part of the Tab controls on the left side are also glitching until the Tab control on the right is moved on top of the Chart. Then the Z ordering works correctly.
Habil
Are these "NXG" type controls? This might be an issue with the specific "family" of controls. I've noticed some peculiarities associated with controls that aren't "modern". Perhaps this is one of them. Try replacing them with "modern" controls and see if it fixes itself. Then at least you can narrow down the buggy behavior to a certain version of the tab control.
If a 2D picture control fixes it, then add a 2D picture control behind the tab control and move it the same way. It's a dumb fix but it seems to work. Try this version.
(You may need to play with pixels a bit, I think the 2D control is sticking out from behind the tab just a touch.)
