Xojo native controls only on mac?

[thorstenstueker]

As a it is called in c++ by reference and described in Microsoft reference guide for it.

[npalardy]

@ivan

Actually it does say that is not using any native call

open & look at ANY window which IS using a call into the Windows API
Pretty sure you will find they are all RBWindow

[npalardy]

Xojo’s C++ code has a class called RBWindow
Inside that there is a reference to the OS window handle
What you see is the RBWindow - I would guess you see one for ANY kind of Window Xojo puts up
But they are, internally, actual windows as per the windows API’s
Its why when you take the “handle”, that internal reference, you can call declares using it
You could not do that if it wasnt a real Windows window

[ivan]

@npalardy

open & look at ANY window which IS using a call into the Windows API
Pretty sure you will find they are all RBWindow

We are talking about DIALOG APIs…
But sure, Xojo has tons of other unrelated API calls used in regular windows

@npalardy

But they are, internally, actual windows as per the windows API’s
Its why when you take the “handle”, that internal reference, you can call declares using it

That is not how Dialog APIs work in windows. Native dialogs DONT NEED and DONT HAVE a container window. The only handler they need it is the one of its OWNER. the owner and the dialog are 2 separated windows.

The owner has whaterver class name given when it was created (RBWindow in this case), when calling the Dialog API, the OS creates the dialog window with class “Dialog box”

[npalardy]

@ivan

We are talking about DIALOG APIs…
But sure, Xojo has tons of other unrelated API calls used in regular windows

IF you assume that xojo simply maps from MessageBox/MessageDialog in Xojo code directly onto some OS API then you’ll be wrong a lot of the time

Thats what I’m trying to point out
Xojo may very well be wrapping a native OS Dialog in an RBWindow class in their C++ framework and THAT is what the Xojo code manipulates etc when you set properties etc etc

But you CAN get access to the “handle” - which is basically the ptr to the instance that the C++ RBWindow class is managing

I’nm ot saying that IS what is happening but that certainly is plausible
Its how a "Windows Button and a “Mac button” turn into a “button” in Xojo
The C++ framework abstracts us from having to know about and care about the internal differences
And they do that with a LOT of classes

@ivan

That is not how Dialog APIs work in windows. Native dialogs DONT NEED and DONT HAVE a container window. The only handler they need it is the one of its OWNER. the owner and the dialog are 2 separated windows.

The owner has whaterver class name given when it was created (RBWindow in this case), when calling the Dialog API, the OS creates the dialog window with class “Dialog box”

Youre missing the point - this has NOTHING to do with how windows thinks it NEEDS to work
This IS how the Xojo runtime works - which is what youre using
Its why you need to get the HANDLE property from a xojo window or control to call declares
That handle IS the reference Xojo lets you get access to to manipulate the ACTUAL underlying OS control

[ivan]

@npalardy

Xojo may very well be wrapping a native OS Dialog in an RBWindow

…

@npalardy

Youre missing the point - this has NOTHING to do with how windows thinks it NEEDS to work
This IS how the Xojo runtime works - which is what youre using
Its why you need to get the HANDLE property from a xojo window or control to call declares
That handle IS the reference Xojo lets you get access to to manipulate the ACTUAL underlying OS control

Lets skip the explaining of why that is not possible and asume that you are right and xojo can embed a native dialog in a window and have handles, lets ignore the differences beetween a Owner window and a Parent window in the API…

Even so, there is no control with “Dialog box” class in the hierarchy of the RBWindow so, No Dialog API is used.

[npalardy]

@ivan

Lets skip the explaining of why that is not possible and asume that you are right and xojo can embed a native dialog in a window and have handles, lets ignore the differences beetween a Owner window and a Parent window in the API…

Even so, there is no control with “Dialog box” class in the hierarchy of the RBWindow so, No Dialog API is used.

not embedding a dialog in a window or any of the other stuff you said

YOUR Xojo code instantiates a Xojo (not Windows) “message dialog”
dim m as new messagedialog
This “Message Dialog” is a certain class in the Xojo C++ runtime
It JUST so happens this is very likely called RBWindow (it could be called Bananas for all it matters)
In that C++ code (which Xojo wrote) they have a property (more than likely tucked away where you cannt see it)

Eventually Xojo will call a Windows API that DOES create a dialog
And that dialogs handle will get put into the RBWindow property that holds the reference to the native dialog

This is how “message dialog is a message dialog is a message dialog” on macOS, Linux & Windows
We interact with the classes xojo provides and they are proxying to the native instance (a bridge if you will)

The RBWindow never inherits from any Windows dialog
You might be able to inspect the properties of the RBWindow using Spy++

But, in XOJO code if you get the MessageDialog handle and pass that to api’s that manipulate DIALOGS if it works then you know the internally there IS a real honest to god Dialog hidden away from your prying eyes

   your xojo code -> has a reference to -> [RBWindow] XOJO messageDialog -> which has a property that refers to ->  native dialog

you dont deal with the actual native control or dialog or window directly
ever
you proxy through the classes xojo provides
and those DO NOT inherit from ANY native controls, windows, dialogs etc

Its NOT as you assume

[JeffT]

@ivan

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.

Can I just say that having worked with Xojo for many many years, and despite being on this Forum for other reasons:

1/ It really REALLY doesn’t look crap to me.
2/ I genuinely don’t see one of these dialogs and get offended
3/ Never once in 15 years has a single customer emailed to say ‘how dare you try to sell an app that looks like this’

OK- not all Xojo controls are native, and therefore the article was disingenuous at best, but hey -life is too short to raise your blood pressure over this.