Christian wrote the plugin API that exposes AN ODBC driver - the driver itself comes from MS
You could get an ODBC driver for PostgreSQL and use that just as easily with a different DSN configuration
This is why I think maybe the issue with the record count might be in the driver - not the API Christian exposed
I could certainly be wrong though
Well, it seemed like a good idea at the time. And it did get better over several releases. I’m sure with some TLC and attention it could become better. But I don’t see Xojo ever bringing it to web and desktop.
I haven’t looked, but are they planning on having simple locking for Android? If so, I’d say that’s a nail in the coffin for mobile whenever that comes out.
This is exactly the work I am outsourcing to the ‘x-platform’ vendor. That is why I am paying for an x-plat license. If the vendor cannot comply with such a minimum requirement…
X-platform development vendors can fail in many ways.
Dunno - I stopped looking at the Android betas some time ago so I really dont know
But native cross platform makes terrible situations with the ui controls. That’s why there is no native java. Native controls are a problem of size and behavior. And Xojo tries to get all of it in one package. That can not work like this when designing outside of any kind of layout management and suggesting the ide designs somehow pixel perfect. It does not but looks like it does. And in that case there should be a MacOS, windows and GTK preview for the app window you are just designing with Xojo. Since you do not have this, ui design for cross platform is playing lottery’s
Auto layout is more or less declarative UI (or well along the road to it). And that is a pretty different paradigm to drag-and-drop, which is the camp Xojo is in. Not that they can’t coexist at some level, but some thought should be put into that.
Bingo. There are fewer attempts to use “native” controls and layouts, and more platforms adopting pixel-perfect approaches (AvaloniaUI makes this a key point; Flutter does as well. Notably, both render via Skia). And users don’t seem to care. I think there are lots of reasons for this:
What users expect are consistent interactions – consistent in the sense of how things basically work everywhere now. Case in point: I think it was interesting that it was noted that textfield behavior across platforms was natively – and noticeably – different.
That you have with flutter, quasar, java swing and many more. Works on all platforms exactly in the same wise and results in clean user interfaces what is needed for the users. But there is a big group expecting native apps for their platform. That even Microsoft had to learn with MD office for Mac which looked like an import from windows and the users did not accepted it. Today I guess most people are not even looking for native or not but for clear user interfaces and intuitive handling.
Yes - the IDE just shouldnt USE auto layout as you drag things into place which is what it is/was doing
THAT was a mistake
It should let you drag & drop then set up the constraints as needed But NOT USE them in the layout editor itself
This is where I find NON-native UI’s fail badly
The dont do text selection and movement in platform correct ways so what I know from other apps that DO use native controls doesnt work. DBeaver & pgAdmin4 I’m staring at you two. Electron based apps have issues as well. Not that they CANT. They just often DONT.
Yes there are trade offs using native controls - Windows controls dont behave the same as macOS or Linux controls so you get “platform behaviour” This might be ok IF your users arent switching between platforms all the time and are used to a specific platforms conventions.
Indeed many have given up since so many tools dont behave “natively” so people are willing to accept “close enough”
Web based apps haven’t helped that as they are or seem to be all over the map as far as how they behave
Users ARE far more savvy now than they used to be
And adaptable
Yeah we have come a long way from the day when we would ridicule them for thinking a CD holder was for coffee cups 
coffee cups ? How quaint ! 
Beer dammit !
Of course we no longer get asked “Where’s the ANY key Windows says I need to press ?”
I have to say, I absolutely love auto-layout on Xojo iOS. Takes a while to understand the concept but once that happens, I don’t want to do it any other way anymore.
My sense, and only anecdotally, is that this line has moved in the last 20 years, and the differences in what you refer to as “platform correct” ways are less than they used to be. We should also separate the feel of these interactions from the look – I’ve previously also heard the argument against non-native (but pixel-perfect) controls that that don’t look the same as the rest of the platform. I definitely think this is almost a non-issue now because of the web.
It would be interesting to identify both the remaining significant interaction differences, as well as the emerging common user expectation for how things work, regardless of platform (the difference between “that didn’t work like the rest of the controls on this platform” and “that didn’t work the way I expected”). This research could guide normalization of a true cross-platform experience.
Text selection is such an integral part of an operating system that when you non-natively emulate it and you screw that up it’s not only noticeable, but a productivity killer. Justifying low quality text-selection in non-native tools just to have a consistent look is the most clear example of style over substance I can imagine.
That’s why I was emphasizing user expectations here; if you notice it (or worse), then it’s getting in the way and not meeting expectations. So, I would not justify it to achieve consistent look – only noting that these are two different things in evaluating a UI toolkit, and that inconsistent appearance (on a platform) seems to be less important to users now than it was 20 years ago.
None of that matters in a database app for businesses. I’ve never heard a user complain about selecting text.
Maybe it matters for app store apps.
I gotta call BS on that. Sorry not sorry. 
Works great for FileMaker. 
Doesn’t work well for Xojo with mismatched control sizes. 
Can say I have had exactly this complaint in various line of business apps over the years
On macOS and Windows
Usually its “something is weird here” or another equally vague statement so I would go actually watch what they do and sure enough they’d use common shortcuts (like cmd+arrow on macOS) and it that doesnt behave as expected then it just feels wrong because it doesnt do like every other app that uses native controls does
I guess some users are picky. None of my users know any difference.
Some were VERY picky indeed
One VP actually was perhaps THE pickiest
And then there are things like the Xojo IDE
When the text selection was “non-standard” there were lots of complaints about that
Of course a HUGE portion of that app IS text based
Then when it was basically all “Mac like” there were complaints on Windows & Linux
So I really tried to fix that and there are/were fewer complaints about the non-standard selection behaviour
Not 0 but a lot fewer