I hope all those great improvements go into the windows framework to fix those flickering soon.
I agree with Christian’s sentiment [quote]I hope all those great improvements go into the windows framework to fix those flickering soon.[/quote]
However it looks like Xojo may undertake “looking into a significant overhaul of the current Win32 based framework… in the future”. That sounds great and is probably needed, but it also sounds like a pretty long term project.
I’d rather that Xojo would - at the least - more quickly address some of the low-hanging fruit in the issues and tickets raised by Julian. Developers targeting Windows clients need real help now to deliver professional projects to clients. I’m sure many would happily accept superficial changes now, rather than a lengthy wait for a foundational change.
The last iteration of the project posted in
https://forum.xojo.com/conversation/post/346119
has virtually no code that affects the UI that I can see - unless I’m missing something ???
But it DOES embody the principles we’ve stated before
https://forum.xojo.com/conversation/post/343709
Namely
- on Windows turn transparency OFF
- set erase background false
- dont overlap controls (see #1) overlapped & transparent is a recipe for flicker
- pass false to refresh & invalidate (see #2)
- turn double buffer ON for controls that support this
there’s no “framework fixing” from the project I can see
[quote=346447:@Norman Palardy]on Windows turn transparency OFF
set erase background false
dont overlap controls (see #1) overlapped & transparent is a recipe for flicker
pass false to refresh & invalidate (see #2)
turn double buffer ON for controls that support this[/quote]
Unfortunately it’s not always that simple. See this topic.
Norman, you are simply repeating your last post. It is good, but it does not take into account the efforts and discoveries of about drawing order. Download his latest demo, 7 posts before yours.
The result of his efforts are quite good on stacked controls.
That should be food for thoughts for the way Xojo draws controls.
Feels like we, Windows builders in particular, have struggled far too much all those years.
One thing: my next Windows desktop project will be a whole lot simpler and quicker to create, based on what we learned from @ .
What must be postponed to give time to implement .Net ?
.Net is Nonsense. If someone wants .Net, Just use Visual Studio. Also, .Net code is interpreted and can be 100% decompliled in no time.
“Flicker is Win32 fault”, its a bigger nonsense.
I have a couple big systems made for Win 2000, last update was on 2013 to include the manifest to use XP native theme, since then, it has been working, Win XP, Vista, 7, 8, 8.1, and recently windows 10, Using the native Win32 controls, drawed with the OS theme, and FLICKER FREE. Some windows even reach the 256 control limit for a single window (vb6 limit), lots of overlapped controls and no flicker.
.Net is not the solution, but, make a correct use of the winApi as says.
This discussion is largely moot indeed, since 's brilliant work which I hope Xojo will build into Xojo.
I did try to use his fix, but unfortunately, it makes all labels opaque. And I could not find a way to reinstate transparency in Xojo code.
Today, it would be nice if Xojo had a look at the UWP architecture. But that is another thread.
UWP wont work for anything < Windows 10 afaik
Would it not be possible to imitate the UWP interface specification with a canvas-based window and canvas-based controls? (now is not a good idea, but perhaps after the flicker fix) While not strictly UWP, it could be made to look identical. Canvas-based controls and windows would work pretty much on any Windows version, I would imagine.
Now, is an approximation such as I describe here an acceptable implementation of the concept? That is a question far beyond my competence level.
That’s basically what WPF does.
If someone can try bellow things and post back feedback regarding to flickering in Windows it would be great thing.
Compile app in Xojo and then go to properties of that app exe file.
Hit ‘Compatibility’ tab and then check bellow options:
[x] Disable Visual themes
(AND & OR)
[x] Disable desktop composition
(AND & OR)
[x] Disable display scaling on high DPI settings
Also should be test as well and only with one of this options checked (turned on and rest of them are turned off)
Thanks to all who try and post back this testing!
While there are advantages/disadvantages with native controls, it would be very possible, however the implementation of a platform agnostic UI framework is a big undertaking, not only in the framework but also in the IDE. For instance Telerik (whom I’ve used in the past) and QT base their whole company on that very idea and are very successful with it.
I’m hoping that with the anticipated release next year of the ability to produce plugins inside Xojo, it will spur the development of new UI controls and maybe a framework by the community if Xojo don’t start this task themselves. Xojo might even take the opportunity to release a few examples of what can be achieved with that new plugin feature and produce a few custom controls which could serve as a stepping stone to spur on further development. If they do it right, there will be an explosion of new UI controls for Xojo, which can only be a good thing as long as they are of a good enough quality.
Only time will tell how things turn out, I just hope they design it well.
Bogdan, it might be best to make another thread with all that in, rather than hijacking this thread 
WPF implemented a whole new UI SDK including proper transparency support, compositing etc etc
Things Win32 really doesn’t do
And WinForms faked
Moving from the current Win32 based framework to one based on WPF would be the equivalent of moving from Carbon to Cocoa. What I don’t know is what that would mean as far as supporting UWP - which is still Win 10 only in any event.
I’m sure we’ll have more discussions about what is / isn’t possible
We always do as things evolve on every target we support
I’m not sure how that would help. Your Xojo code can’t really create the controls now, how will a being able to create a xojo based plugin further that? Your code would have to be a mass of declares, so why not use a proper low-level language to create the control?
For the same reasons that people are coding in Xojo and not C# or C++ be that speed of development, ease of use, familiarity or some other reason personal to them.
I could come up with a list of controls as long as my arm that I want to add to Xojo but what I don’t want to do is get involved with baggage involved with the current plugin system for all the different platforms, it just doesn’t interest me at the moment.
I do need to make some controls, be they canvas based or a wrapped group of existing controls (without using a container) and having no IDE UI feedback for them is a real negative for me. You could quickly end up with an interface that just looks like a bunch of rectangles. It would be immeasurably better to have a nice self contained control from a plugin that did what I wanted and provided some visual feedback to the IDE.
However, as almost all native controls are already covered by Xojo (at least in windows) the need to create native controls isn’t that important. Many controls can be simple tweaks on existing ones, add a few graphics around a textbox with no border and you’ve got yourself a nice text based search control.
Why would I want or even need to drop out of Xojo to make that plugin, fire up VS, XCode etc. code it up, cross compile it, package it then rinse/repeat when there’s a bug when I could just make it in Xojo?
Non-native controls are becoming increasingly prevalent. Many companies are release big cross platforms apps with custom drawn controls, its less of an expectation for users these days. UWP on windows goes to show what can be accomplished without using a single native control as the entire interface is essentially in a canvas. A UWP app can be so clean it can almost look like an iOS app and would be similarly at home on windows, macos or linux.
Fair enough. I was fixated on native. But maybe that ship has sailed (again).