In TOF they discussed about the xojo native controls. There is a really interesting thread beginning about the controls here:
There they are writing about native controls and the really nice working native mac controls of xojo 2021. Nice. But. The Windows Controls are not really working native as you can see in that discussion and as I can tell from here, the linux controls are also not really in the correct use.
Somehow they look like assembled byself and not used natively. But in that moment I am asking myself: for what I should need it if the controls are not really native and it is not really cross platform?
I’d say, if controls are native or not has nothing to do with cross-platform. Cross-platform just says something about whether I can create apps for every supported platform. Even if these controls are not native, they can still be “good” or looking native and so on…
(I am NOT saying that Xojos Controls on Win/Lin are looking/working good!)
I know what you want to say and the aspect of being cross platform in case of xojo I was only mentioning because that is a real problem. I can remember that, when sun was starting whith java swing they mentioned first to use native controls. They gave up really fast and where building Swing on not native control sets with own rendering engine.
Xojo claims that they are cross platform native. Exactly that is for me the point. It is not entirely true. Thay have leaks in their controls. Not really in their mac controls but in the windows and GTK controls under Linux.
As I understood @ivan 's research, even if they’re not going to use TaskDialog for MessageDialog, they’re still using the wrong API and just throwing up a general message box.
The other way around. It would be nice if they use a general message box, at least those are native dialogs with the standar colors, alignments, sizes and behavior.
Xojo uses NO DIALOG API at all, the MessageDialog is just a regular xojo window with buttons.
So, when you have an App that uses native dialogs like Msgbox and others with MessageDialog, it looks like crap to have some of the dialogs native and others with a regular window.
Sure, you can tell lets use only MessageDialog instead of Msgbox… Not really, if you use any Other dialog like open file, save file, etc, etc, all the interactions (overwrite, this file dosnt exists, etc) will be a native one…
So, the dialogs are NOT native and Xojo did not even try to emulate the colors, sizes alignments. That speaks a lot of the quality of their product, call it halfbaked class or just crapy implementation but in the end, it is just unusable for a serious app.
You can see that in Xojo IDE, for example, closing a test without saving it will prompt you:
If you click yes and try to save with the same name as other file:
msgbox is a native dialog, MessageDialog is a hand coded window used by the Xojo IDE to have some crapy looking dialogs since forever, someone at xojo just thought it was a good idea to make them available for the end users.
I have 3 xojo versions installed to mantain proyects, note that the dialog is identical, but MessageDialog was exosed only on the 2019r2. Also note that they are using native icons in 2020+ for MessageDialog and the internal dialog show exactly the same chage:
And all are “native” api’s but they all can appear quite different
Has anyone just pointed Spy++ or similar tools at one of those open dialogs to see what class they are ?
That would be instructive - and definitive
I made some little update to some proyects, just to avoid a rewrite and I can mantain with just those 3. Xojo breaking the “framework” every few releases
Actually, MessageBox and MessageBoxEx are the same, without hacking a Msgbox to alter the buton captions, I think that the correct API is CreateDialog but, xojo uses non of them for the MessageDialog
How do you know the MessageDialog is not from another native dialog from a different set of Windows API, as Windows has several of them? Have you compared all the different sets to conclude none provide a dialog like the MessageDialog?
How did you come to the conclusion that Xojo made their own instead?
Because of the used class byself it is evidenced that there is a self taylored window instead of the windows dialog class [quote=“npalardy, post:12, topic:1643”]
what class they are ?
[/quote]
Right but they are, with varying options, quite configurable
RBWindow unfortunately doesnt say whats underlying it
I was hoping to discern what API they might be calling as it could still be one of those but with options that make it appear different
RBWindow
[/quote]
This actually doesnt say what OS native type its wrapping - RBWindow is just a “container” more or less
Like a proxy object that actually points to some other native instance
Just look at Ivan’s ScreenShots.
Those Dialogs with “gray background” are maybe “native”, but not what one would like to see.
To have the application look current, it should use the version with “white background (content)”, “gray background (bottom, where the buttons are)”. And especially not a mix of both.
Combine Xojo’s own custom dialogs with their issues with Multi-Monitors that have different Scaling (positioning is a nightmare and not working properly). That’s what they provide. Yes, it’s “x-platform” and “native”, but…
That’s why we’ve implemented own wrappers for showing and positioning Dialogs, own Methods that use Declares to show the proper dialogs (MsgBox, Message/Task-Dialogs - heck, even MsgBox they’ve updated not too long ago) on Windows, … a lot of work and workarounds for pretty basic stuff.
Similar story most likely with Linux.
One that comes to mind: feedback://showreport?report_id=49506
A simple “MsgBox” is not properly localized. Do it yourself using gtk Declares and get the expected result.
Doesn’t quite help to trust in the Xojo-Framework if such basic things just don’t work as they should…
It’s good enough for some quick and dirty - simple, personal, in-house stuff. But for professional use…?
If one works daily with Windows, it’s pretty obvious many things are not quite right.
I have some feeling that most Xojo Developers are using macOS for most of their daily business.
That would explain why they notice what’s needed on that Target. And Windows/Linux - hey, it works.
It’s that subtle things that make it great - but of course I wouldn’t even notice it when not using and working with the Platform on a regular basis.
