Lets not get off topic or this thread will get locked, try to stay talking about the problem at hand please, the problem and not how Xojo is marketed, make a new thread, they are free
I have just added a project and write up on some more testing. Iāve gotten to the end of what I can do without seeing source code so I have to leave it there for now. If Xojo want to keep it as a feature request and ignore it for 1-2 years like some of the feature requests on the list then that is their prerogative but comments in this thread alone are showing that itās a problem that is effecting sales and renewals that is easily in the multiple of thousands of dollars.
Can you give it a try, let me know your feedback etc. if you find that something doesnāt work with those tweaks let me know (like labels over controls that are now fixed) and Iāll see if I can work those out.
Fingers crossed that Xojo is actually working on this and not just hoping that we forget about it because that would make me
As a single data point, I have written a hundred or so Windows apps (accounting, inventory control, etc) that do some fairly sophisticated data entry (editable listboxes with popups, autocomplete, etc) and have never had to deal with flicker. It is quite possible for a new user, or even an experienced one, to create apps that adhere to Xojoās claims. There are certain kinds of apps that are prone to flicker, and many others that are not.
[quote=344229:@]Fingers crossed that Xojo is actually working on this and not just hoping that we forget about it because that would make me
Feedback Case #47001[/quote]
FWIW Iāve added it as my top case. Additionally Iāve postponed my Pro renewal until I see real movement on this issue. (Love Macs and Linux, but Windows pays the bills!) Apologies for the tangent.
This is very true.
Small apps with 5 controls on a window will be fine.
Complex interfaces suffer , (and are also difficult to work up as UWP style apps with their toybox controls)
While we are bound by Desktop controls in Windows, the main issue seems to be getting the zorder right.
Thats the important first step.
Adding a ācreation orderā to the properties of visible controls and respecting it , could get us there.
While stacking controls is not recommended, Julianās study of the order of drawing is by now fairly clear. It seems pretty obvious it is linked to the Z-Order. So in fact we already have the creation order.
The other major offender I bumped into is painting in an underneath control. Namely, never use the paint even in a canvas that sports other controls. The canvas is a decent container, and without anything in Paint, it does not flicker that much during scroll. But paint even a dot, and you get the fireworks.
Note that the very same happens if you paint in the window event. Catastrophe. That is one occurrence when using the backdrop property makes it way more stable.
Unless someone produces a toolkit, Modern UI apps will still require work, and I persist believing that the best way to go is to use a single canvas, or maybe an HTML/CSS/Javascript page in an HTMLViewer.
Modern UI is based on XAML. Note that we do have access to the next best thing with Jeremie Leroyās Skin Creator Tool. While I did not have the occasion to work with it, his UI builder based on XML is the closest available. It should be somewhat simpler than the solutions I mentioned above.
Did the sameā¦added it as my top case and will wait for progress on this one way or the other probably before renewing again. Either make real custom Windows controls that work right, or fix whatever underlying issue is causing it. Kludges and workarounds arenāt ok with me in the long run.
I totally agree Tim, thatās why I donāt want to get into āwhat xojo claimsā, Iād rather keep it about hard facts. I only started to look into this when I was talking to Michel on another thread and noticed he was having issues with interactive controls popping in front of another control. The modifications sorted that out pretty quickly (see the three stacked rectangles with the textbox occluded) and as you can see below, my modifications also sort out Michels problems with controls in front of a canvas.
Hereās the difference, there are two windows here, the top window show how xojo is now, the bottom window is with my modifications:
The top left image is a canvas with a textbox inserted into it in the IDE (so the red box appears around the canvas as you move the text box inside). As you can see the text box is there, but its being overwritten so much its hardly visible. This is with erase background turned off on the canvas and transparent set to false and invalidate(false) being used in the timer.
The top right image is a canvas behind a textbox, the textbox is separate from the canvas and has been moved into position using the Top and Left property rather than using the mouse (so it doesnt embed inside the canvas as in the above example). As you can see, there is flickering. This is with erase background turned off on the canvas and and invalidate(false) being used in the timer.
The bottom image is a canvas with a textbox in front (similar to the top right example). Zero flicker, even while editing and interacting, Iām my opinion, this is how it should be, out of the box.
Iām currently unable to replicate the top left image (embedded controls in the IDE) with my alterations as the framework seems to be performing another refresh of its own. This is evident because Iām not actually doing any background clearing or green filling on ANY animation on both windows but the background is clearly being blanked or there would be a trail of footballs left. Iāll document this in the ticket.
All these demos are using the paint event, not background property modification.
That was done placing the controls in reverse order then applying the my tweaks. Hereās a copy of the latest revision that Iām working on at the moment, have a look:
Can you elaborate on the āplacing the controls in reverse orderā portion?
Are you referring to the Xojo z-order you can change in the IDE? Or do the controls have to get added to the window in a particular order? If so, and you later need to insert a control, do you save the project in XML or text format, then close and edit in a text editor, then re-open?
Youāre making some astounding discoveries considering you do not have the source. Keep up the good work.
[quote=344477:@Douglas Handy]Can you elaborate on the āplacing the controls in reverse orderā portion?
Are you referring to the Xojo z-order you can change in the IDE? [/quote]
Yes
It can make it a bit awkward to edit in the IDE as large controls that you would normally have behind a smaller control are flipped and the big control then gets in the way of selecting the smaller control (as its being) so you need to use the side nav to select the control or use a bounding box selection and shift click the control you dont want in the selection, but yes you need to reverse the order using the buttons at the top of the window:
I just send all the controls to the back that I was to be at the front during runtime using the last button on the image above.
If you add another control later and you want it on top when run, just send it to the back in the IDE.
Iām having a play with the control ordering a mo, making that video got me thinking about re-ordering the controls using declares, I dont know if Iāve done this before, I might have and found it not to work but I canāt remember as this has been floating around for so long now so Iāll give it another try and report back soon.
Automating control ordering should be possible, which would avoid the somewhat counter intuitive reverse placement in the IDE. SetWindowPos should do it. It should actually be possible to completely automate the stuff. It would take using GetWindowPosition to have the current position as set in the IDE, and use SetWindowPos to reverse that order. You could actually create a small class that gets all controls in the window open, and reverses their ZOrder.
Maybe that would require to start invisible, to avoid some flicker when SetWindowsPos is applied, and then reveal the window with its new drawing order.
Actually, it should be pretty easy to come up with, by wrapping GetWindowPosition and SetWindowPos in a couple methods. Then all the rest of the code can be done in Xojo.
It could even improve on RubberViews on Windows, which can be pretty bad when used in the Resizing event with lots of controls.
You dont need to GetWIndowPos because you can tell it to ignore the position and size when you call SetWindowPos by specifying SWP_NOMOVE and SWP_NOSIZE in the flags so it will just be changing the ordering.
Whoever said rubber ducking was rubbish I have no idea why I didnt reimplement this way back when, after all it was what directed me to the problem. I can only assume that it was late or I wasnāt up to speed on things back then.
You can now use the same forms between osx and windows with the fixes shown above.
The only thing you need to watch out for now is embedding your controls inside other controls that are changing/animating, this is probably an extra refresh bug that Iāll post when I have a chance.
To get around this just note the position of the control, move it out of the parent control (so the red box goes) then change the Top and Left property to move them back (see my video above for an example of that).
I have no idea why I didnt reimplement this way back when, after all it was what directed me to the problem. I can only assume that it was late or I wasnāt up to speed on things back then.