The best way I found so far is to start window invisible, and 300-500 ms later, make it visible.
Managing rendering is not impossible, but it is potentially cumbersome. Especially since there is no way to guess the order of drawing. It would have to be the result of massive use of System.Debuglog.
I can’t get Xojo 2017r1 to flicker either. Now, having said that, I can’t remember the last time I launched the IDE in Windows so I can’t say if that’s been true for a while.
Yes, the controls do still flicker.
It seems only canvas paint is much faster.
Despite running in VMWare, I can see a difference between Pre-creator and Creator. While it didn’t eliminate all flicker it reduced it a LOT. I think this will be a good version (assuming no other bugs). About time, Microsoft.
I will have to download creator and test it in a VM.
Thanks all for the good information.
I get this feeling too 
There is no guess work involved, I can guarantee the order of drawing, it happens in the reverse order that the controls are ordered by using the four order buttons at the top of the window.
Thanks Christoph
I’m not sure that VM testing will prove anything as they could just have improved the rendering for VM in general. Hardware testing is where things will be confirmed or not.
If anyone wants to PM me some apps or code to test, I’ll get a spare box set up over the weekend running Creator and let you know how they compare with my non-creator current install.
Interesting to see such certainty.
In fact, drawing is in the order fixed by these little buttons, but when they are not used, in the order they were added to the window.
When there are quite a few controls, it can become difficult to deal with.
[quote=326200:@Michel Bujardet]Interesting to see such certainty.
In fact, drawing is in the order fixed by these little buttons, but when they are not used, in the order they were added to the window.[/quote]
I am 100% certain. Yes, they are drawn in reverse order to the order they are added to the control but as that can take place a long time before a form is finally finished I consider it a mute point as it is easy to forgot what what added and in what order. The “easy” way to reorder them is using the 4 order buttons as indicated. It would be nice if there were some visual indication of this order as neither Tab order nor the order they appear in the navigation reflect their actual render order. But as the IDE should be WYSIWYG I guess there is no need if everything was right in the world 
If you want to know more, have a read of:
Xojo framework z-order backwards? - Windows - Xojo Programming Forum and <https://xojo.com/issue/47001>
If you recall I pointed you a fix for TextBoxes popping through other control when you mouse over it. That fixed stemmed from all the above research.
The easiest method to ensure things are rendered correctly and dont pop though is to put all the controls you want “nearest the users” to the back and run the script I wrote to “correct” the controls sytle. But that does unfortunately make the IDE look like a dogs breakfast while editing if you have lots of layers and controls overlapping.
Only then will you have the most chance of not having a flickering control as Xojo wont be fighting with the inherent way windows is rendering the form.
However, all that being said, it would probably totally break the macos version if you reversed the control drawing order to fix the windows edition, I’ve not tested that and I doubt that I could hook in low enough to programmatically change the order before the render takes place.
Not here. They open in the order they are added to the window. Just tested under 2017R1.
Not talking about those which zOrder has been set in the IDE.
When they are partially or entirely drawn after the control underneath, they flicker much more.
How did you test that?
Very simple. Added the controls, and into each control open event, placed a System.Debuglog me.Name.
The order that Xojo processes the controls event isnt related to the order which it is drawn on the form at the OS level.
OK. If you say so.
I don’t say so, Microsoft’s Windows Kit Inspection Object (inspect.exe) tells me so.
Read the first few paragraphs of https://forum.xojo.com/38658-xojo-framework-z-order-backwards if you if you don’t believe me.
I converted over a regular Windows machine this afternoon and took video. Significant flicker reduction from before/after using the exact same file.
Nice Bob, was that your own program or the example I gave above?
I used the next version of Shorts as my example since I’ve been knee deep into for a few months. It’s using a canvas inside of multiple nested container controls.
Pre-conversion it flickered really bad when resizing the designer window. Post conversion it flickers a little when the resize is done and that might be from something I’m doing to force a refresh. I’ll have to dig into it more but I’m excited to see this.
I mostly see huge improvements in paint events. For example just filling an entire window in the paint event triggers flickering all over the place. In Windows 10 Creator, no/nil flickering is seen at all.
I wonder what MS changed in the new Windows version. Faster DirectDraw?
Not sure, but the timer interval changed. The global frequency of the timer interval used to be 15.6269 milliseconds, and now its 15.6265 ms. Something has been changed with the timer. 0.0004 milliseconds shouldn’t make a difference, but its enough of a change to know something has been adjusted.
If Xojo uses an internal timer for drawing, then something has been optimised - just guessing though. Just some friendly thoughts - please don’t use a timer for your programs when drawing on Windows OS - the timer is for slow events. Use a for-next loop in a thread instead for fast refreshes please 
I think most/all of the professional game engines on Windows OS use a version of a For-Next loop.