I’ve been working on this issue for about a month now myself. My issues are caused by using custom window styles so I can remove the title bar which forces me to resize the window myself in the mouse events.
Have you looked into FreezeWindow in the Xojo WFS? It might help depending on what you are doing.
IMHO, these controls are fundamentally flawed in the framework and any amount of trickery isn’t going to fix this.
Even moving them 1 pixel causes them to flicker so a fps limiting system isn’t going to help this.
My only suggestion would be to place everything inside container controls, set their locking method as desired then just move the container control around. See if that produces any better results.
Just tick and untick the box and see what happens.
You will notice that the radio’s are still having issues, I never had any feedback from Xojo about that, windows love is unfortunately severely lacking.
There might be issues where having individual controls on the window and refreshing them all in a row causes issues, if you have them in the container control will only cause a single “draw” in the framework (who knows).
Thanks, getting an sms from twitter at 3:30am reminded me that I should turn that function off
You’ll be lucky to get any custom drawing done. Until this is fixed (if ever) I feel there’s no chance getting to the bottom of any of this.
If you’re going the route of creating your own double buffering routines, doesn’t it kind of defeat the point of using a framework that should be taking care of all that?
[quote=332777:@]Thanks, getting an sms from twitter at 3:30am reminded me that I should turn that function off
You’ll be lucky to get any custom drawing done. Until this is fixed (if ever) I feel there’s no chance getting to the bottom of any of this.
If you’re going the route of creating your own double buffering routines, doesn’t it kind of defeat the point of using a framework that should be taking care of all that?[/quote]
Apologies for that late notification.
I agree but I have to try and fix it somehow. I can’t stand the flickerrrrrrrrrrrrr.
Thanks so much for the link to your Z order info. I will study it and see how this info can help me.
I have found that SetWindowPos produces less flicker than resizing using something like Window1.Width = Window1.Width + x in MouseDrag in my custom windows. Most likely related to what you have discovered no doubt.
Flickering is much less noticeable with Windows 10 Creative update. But still there is some.
Unfortunately you cannot remove it completely because Windows itself does not use double buffering at all. macOS does and that’s also the main reason why flickering is a no-issue on macOS.
I have an app I designed for macOS that has 3 splitters (1 vertical, 2 horizontal), not to mention a few controls that appear/hide based on the current app state. On macOS this works great, and looks wonderful.
On Windows it is an awful mess…
Some of the declares and such I have found around here don’t seem to help (not to mention were 32bit only)
I have tried to add #IF target to delay some of the live screen refresh…
but that looks even worse as the splitters are now over the panes until you release the mouse, and then sometimes the screen doesn’t redraw “right”…
I managed to reduce “most” by delaying the update of everything on the window except the one slider being moved until “mouseup” event… it isn’t perfect (but then it IS Windows ), but is better than the strobe show I had before…
I also found that by moving the z-Order of the splitters to the front helped a lot, since it wasn’t trying to redraw things it didn’t need to