In your demo project, I still see flicker on the left textfield over the balloon, in Window2 lower left. Yet you use zOrderFix in Open. It should perform like the one on the right, should it not ?
The SetWindowPos() API flag for SWP_NOMOVE means ignore the top/left position (i.e. do not move it) and SWP_NOSIZE means ignore the width/height (i.e. do not change the size). So you don’t need to retrieve those first. In essence, he is using SetWindowPos() to change only the other attributes, namely the z-order. In case it is not obvious, the SWP_ prefix on the constants refers to [S]et[W]indow[Pos]_
I understand you don’t want to change the control position or its dimensions, but to reverse the zorder, I should think that you need to get it first. Since Xojo does not provide it in code, it would seem necessary to know what is front, middle and back, to make it back, middle and front (or more complex).
Re-download the code and take a peek in ZOrderFix, its just a for loop that goes through all the controls on the form and changes their order. Thankfully the order of the controls in the loop is the order that they are rendered in xojo.
So you just get the handle to it, which I do with:
win.Control(i).handle
i.e.
ok = SetWindowPos(win.Control(i).handle, HWND_TOP, 0, 0, 0, 0, SWP_NOMOVE Or SWP_NOSIZE)
So you don’t care where the control is on the form, you just bring it to the TOP which is actually the back (Xojo logic). This means that the last control in the for loop that would be in the highest z-order actually ends up at the back of our modified version which is exactly what we want.
That is the detail I did not get. I wondered why I did not see GetNextWindow anywhere.
Any idea why the left textfield over the balloon flickers in Window2 ? The one on the right that is already reversed is solid as a rock, the one on the left that I would assume your method has put in the right order should not flicker, right ?
It’s because it is a child control of the canvas.
Putting this in the open event of the textfield fixes the problem also.
me.Parent = nil
Ah. So it is not as straightforward as I thought. Some additional precautions are needed.
Indeed with parent = nil it is as solid as the one on the right.
Thank you.
Where is Xojo’s take on this?
We are implementing it?
We are working on it?
We’ll make the z order accessible in code?
We’ll have a build-script for Windows which reverses the z order?
Big thanks to Julian?
Even an explanation on why Xojo uses a weird z order on Windows (necessity? error?) would be appreciated.
Wrote to Geoff and asked him to chip in
Without getting deep into the glory details (though I’m sure Julian may attempt to as he’s a smart guy) but there’s nothing “weird” about it from a Xojo perspective. Your z-order (i.e. drawing order) follows your control stack on your window layout. It’s however, completely backwards on Windows when dealing with Win32 controls that are not transparent (yes WS_EX_COMPOSITED would help, but note the caveats, rabbit hole, rabbit hole, etc.). The fortunate part of this is with our move away from transparent controls we can start ordering them the “correct” way on Windows. As of now the z-order only matters for actual Win32 controls and only when you try to overlap them (but why would you want to do that). Of course, when we start taking away transparent controls I’m sure someone will attempt something like this:
And complain that we totally got our z-order wrong as well 
So are you saying all controls were previously created as transparent controls but that is changing? And when you do you can reverse the Win32 ordering to help solve/reduce this flickering?
Not exactly, native Win32 controls (and by this I mean things like PushButton, RadioButton ,Checkboxes, etc.) are not truly transparent controls (and if I must clarify I mean simply they are not created with the WS_EX_TRANSPARENT flag set), but things like Canvas, Labels, PagePanels, ContainerControls, and a host of other non-native Win32 Controls are (i.e. BevelButton, ProgressWheel, etc.). You do not want to reverse the z-order for these types of controls since they are already in the correct drawing order. I don’t see how adjusting the z-order solves flicker at all unless you are purposely overlapping native Win32 controls. Removing truly transparent controls will solve most flicker issues, and at that point we will need to correct the z-order.
I did notice trying Julian’s ZOrderFix on one of my program that has transparent ContainerControl in front of other controls, that made them non transparent, yet their zOrder was not changed.
It is pretty obvious by now that ZOrderFix is not the magic pill more than declares that stop redraw, or other expedients. I use much too many canvas and containercontrols to rely on that.
For now on, I will be slowly refactoring my Windows programs to simply do away with conventional controls, in favor of a single canvas UI.
We are evaluating the potential solutions. The details are available on this case:
<https://xojo.com/issue/47001> and in William’s comments here.
Just heading to bed, thought I’d share where I’m up to. I’m trying to get everything working that I can think of, the only issue I have right now is a tiny bit of flicker on a label control that is over the top of an animating canvas control (static is fine), but it ONLY happens after you have resized the window so I’m not sure why that is happening. I might end up ignoring that considering you can get around that by rendering your text into the canvas directly instead of floating a label over the top… but I digress…
I’m playing with some different controls on the form now to see what works and what doesn’t. In doing that I’ve just come up against <https://xojo.com/issue/38838> so I’m currently distracted scratching my head on that one. I was =O when I saw the creation date of that ticket. I have my own checkbox on the form (using declares to add it) and I can modify the background, but not the xojo one. I’ve asked William for some input about that so I hope he has a few minutes to get back to me on it.
I’ll be updating the ticket over the weekend.
I have not had much time to play with it, but from what William explains above, I should probably modify ZOrderFix to let it ignore Canvas, Labels, PagePanels, ContainerControls, BevelButton, ProgressWheel, and my project should probably be fine.
I am a bit concerned that William seems now willing to modify the way Windows controls are drawn, and that it will interfere with ZOrderFix.
Hey all.
Excuse me for my bad English (Swedish). I have big problems with “flickering” when I compile my code to windows (develops on mac). I think about to switch back to Visual Studio because my program gets really bad. It’s not just canvas, it is when I press Tab between text boxes, Labels blinks, Listbox flashes when I double-click them… Will there be any correction on that? Doing a “work around” to reduce problems is not a solution good solution.
//Micke
There are other threads on the forum on how to reduce flicker. I’d start with them.
[quote=377418:@Mikael Guss]Hey all.
Excuse me for my bad English (Swedish). I have big problems with “flickering” when I compile my code to windows (develops on mac). I think about to switch back to Visual Studio because my program gets really bad. It’s not just canvas, it is when I press Tab between text boxes, Labels blinks, Listbox flashes when I double-click them… Will there be any correction on that? Doing a “work around” to reduce problems is not a solution good solution.
//Micke[/quote]
Your error is to develop on Mac. Mac does not show you any flicker, so you don’t have any chance to optimize properly for Windows.
Mac tolerates stacking of controls, which is a major reason for flicker on Windows.
To develop properly running Windows programs, you need to do that on a PC, under Windows. Or at least accept the fact that a project started on Mac cannot simply be compiled unchanged on Windows without optimization. It is not a matter of workaround, it is a matter of understanding the particular requirements of the Windows environment.
I have a program that exists in both Mac and Windows. A while ago, I decided to drop the common project, and have different source for Mac and Windows. The Windows part does not flicker at all, but the layout is sensibly different from the Mac part.
Now indeed, you can go back to VB. It will be a painstaking task to move your program to it though.
Or you can try to learn how to properly use Xojo under Windows.
Au !