I’ve build several containercontrols having a groupbox-control inside. All worked fine, till I resized some application windows during testing this morning. What I saw what that the groupboxes where not properly repainted during resizing. I checked Feedback on this and saw quite some old issues about groupbox in relation to container control, some unclear being fixed or not.
The workarround was not difficult, just avoid having the groupbox as a part of the containercontrol, but it has cost me quite some time reworking all these container-controls and test everything again.
So I would say: avoid using groupboxes within container-controls. !!
I’ve thrown in the towel regarding painting/flickering issues on Windows and now use the WIN Performance module by @Oliver Osswald. It works great and I don’t spend hours on these issues.
Here’s the thread: windows-flicker-switch-off-performance-options
Mind you, I’m writing for vertical markets and have more leeway in what I can push out. Using this module probably wouldn’t work in a retail commercial application.
Add your support for .NET controls to <https://xojo.com/issue/28733> (currently 10th).
Changing settings at system-level ? All thought Microsoft sometimes seems to do it themselves, think this is not the way to go.
About groupboxes, I wanted to see if the issue with the label being opaque presented with VB, assuming that .NET would be more consistent. Well. The groupbox there is not transparent…
That said, I did put my points on the request for .Net support.
I see the kind of angry calls for support “you have broken my Windows” …
In my case it’s only active while the Xojo-built app itself has focus. As soon as the context switches to the OS, or a different application, the users preferred settings take effect. If the settings persist beyond the Xojo app then you’re doing it wrong.
In practice, it’s a minor difference to the user (really, how often is an app resized?), and avoids tons of flicker and redraw issues.
Like I said, it’s not for everyone, but in my case it’s become part of my standard Window subclass.
I can imagine @Tanner Lee , sometimes you’re done with it. When it doesn’t work the way it should, then it justifies draconian measures.
[quote=201113:@Tanner Lee]In my case it’s only active while the Xojo-built app itself has focus. As soon as the context switches to the OS, or a different application, the users preferred settings take effect. If the settings persist beyond the Xojo app then you’re doing it wrong.
In practice, it’s a minor difference to the user (really, how often is an app resized?), and avoids tons of flicker and redraw issues.
Like I said, it’s not for everyone, but in my case it’s become part of my standard Window subclass.[/quote]
I tried to implement just that. Until my app crashed and I was stuck with the settings. Shacky…