No way, Xojo uses Unit tests! 
After having my pilot Xojo desktop app humming away perfectly on MacOS, upon porting to WIndows and working with the Windows version of Xojo, there are a bunch of little issues that shouldn’t exist after all this time on such a mature part of the platform:
-
Text fields, including the text field portion of drop-downs, behave differently. I haven’t delved into it yet but I think it is mostly that upon entry to a textbox, the textbox value is preselected as if the user had pressed Option-A on the Mac. On Windows this doesn’t happen. It isn’t that one way or the other is “right”, it is just that the inconsistency breaks the concept of cross-platform abstraction. There is also something broken with drop downs as I had incremental search / match as the user typed working on MacOS and it doesn’t function at all on Windows (no declares or anything like that, just straight-up Xojo Code).
-
At least using ODBC with two-way cursors turned off and MBS Sql driver, any attempt to use rowset.Count results in a not supported error, with ugly workarounds.
-
My architecture keeping short accounts with DB connections worked perfectly on MacOS / Postgres and fails utterly on Windows / Sql Server vis MBS. The basic fix was to hold a static DB connection for the life of the app. For this CRUD app I don’t really care but to me it’s unprecedented for such a fundamental variance to crop up based on back end.
-
DB queries run much more slowly overall, most noticeable on larger query results (10K+ rows). There could be a lot of reasons for this, so in fairness I don’t necessarily lay this at Xojo’s feet. But I suspect in the end they will have a role in it, lol. (I have batch count up to 2,000 on the ODBC driver, which seems to be where the law of diminishing returns kicks in; Christian suggested 100 as a starting point).
-
Some controls carefully aligned in the MacOS UI are a pixel or three “off” on Windows, although in no instance I’ve seen yet does it rise to the level of “unusable” or “annoyingly ugly”. Just looks like careless layout. This is not just my laid out controls but things like Xojo-generated dialog boxes where buttons have no whitespace between their bottoms and the modal dialog, or may be even a pixel or two off the bottom of the dialog. (I actually kind of anticipated some of this and if this were the only problem I would scarcely mention it. Sadly, it’s not the only problem).
-
The IDE itself behaves oddly at times. Leaving a workspace up and coming back after logging out and in, the Xojo window is empty and I have to “open a new workspace” to see the already-open project, then close the original blank window (or exit Xojo and restart it). This never happened in MacOS.
I probably have 3 days of work into getting past connection issues and reworking DB-related code (apart from the difference in SQL syntax, which I planned for) and while this is better than rewriting it for Windows it is not the sort of “It Just Works” experience implied by Xojo marketing, either. By contrast, going in the other direction a couple of years ago, my entire .NET data access layer library for Sql Server under windows ported to compile and run on MacOS against Postgres, with just a substitution of a different library for System.Data.SqlClient / System.Data.SqlTypes. There were no performance “gotchas” and no unsupported features.
People often decry this sort of thing as an indication of insufficient or nonexistent unit testing, which may well be part of the problem, but I see it more as a lack of higher-level integration and regression testing.
And yes I could file tickets for all this, but then Xojo would expect me to do more than write up a good and valid ticket, it will be on me to write sample projects to irrevocably demonstrate / prove the issue and then it will be marked “reproducible” and probably sit for 2 years and be closed. They will also expect me to be willing to do extensive research and work arounds for things that don’t work as advertised and I almost have to show that there are no workarounds to even have a chance at a fix.
I have a couple of tickets languishing out there from my early weeks of working with Xojo, most notably that TableColumns() is broken at least in Postgres … it is a straightforward fix for a documented API function but probably because No One Else Has Complained, it will end up unaddressed.
2 Likes
That specific one I dont know that a unit test would have caught
BUT that is was documented as a PROPERTY so “What the heck we should make it a property because the docs say its a property” doesnt give me much faith they understand the impact of such changes
This is a trivial change that broke code in very non-obvious ways
Renaming properties has as well
Control BackColor Property Shadowing Broken
That Oh gee we’re sorry we broke your existing giant project. You should update it seems to be the level of concern and understanding for what that did is beyond disappointing
-
I think both of these are in fact fully native controls and behave as the platform native controls are supposed to
-
This MAY be an ODBC issue. It doesnt seem it should be but there are notes about some data sources not being able to tell the row count without fetching the results
SQLRowCount Function - ODBC API Reference | Microsoft Learn -
this seems really odd
-
have you tested the queries in SSMS directly and analyzed them ?
There might be something to tweak in the DDLL to add indexes etc that might speed things -
yeah control sizes are different when you run on windows and that may affect alignment
No “automatic” way to fix these & deal with them can mean a bunch of code for each target to tweak things
-
yeah. Sadly
self fulfilling prophecy on their part
because its onerous to submit a report that WILL get looked at many dont bother
Hey look we have fewer bugs ! Quality is going up !
or worse, someone does but few “thumbs up” them because “why bother ?”
Oh look only one person voted for this it cant be that important
even though it might be a compiler bug etc that is just a matter of time until others hit it as well
It used to often be said on the old old forums and mailing lists that if someone else already reported it why bother doing it again ?
I have no doubt that attitude still exists
Or people just dont bother even reporting at all
Apathy will hurt them more than anything
I think this is a side effect of Xojo using native controls which naturally have different dimensions on macOS & MS-Windows (probably Linux as well). We solved this by subclassing the controls and applying offsets in the control Open event.
1 Like
Yeah I get that. One has to be biased toward platform fidelity or else consistency and no one will be completely happy whichever way you go. But then at least document the differences. In my case I want it to behave in certain ways not because its Win-doze but because it’s the best and most effortless flow for the user (mostly me). I’d see this as a set of behavior options that will default differently according to what each platform expects, but can be overridden if desired. So in this case, it might be SelectTextOnEntry = true of macOS, false for Windows.
Sure, but at least their own dialogs should self-adjust, something like, top left of button plus button height has to leave it at least 10 pixels from the bottom of the canvas or whatever. The combination of me seeing things like this on a target platform that’s been full-throat supported for not years but decades, speaks to a lack of pride of craftsmanship IMO.
They are all queries without ORDER BY or WHERE so there’s nothing for indexes to work with. They end up in a listbox for browsing and ordering. I realize I may have to put a default TOP n on a couple of them as they can’t grow without bounds but the point is that on MacOS / Postgres I was loading 25K rows in < 1 second and now it takes about 30.
In my (quite possibly naive) opinion, the driver could take the SQL behind a given rowset and do a COUNT(*) query, lazy-executed when Count is referenced for the first time, to provide this info, if the underlying DB lib doesn’t provide that info. That would be better than breaking existing code or assuming all use of the driver is in greenfield projects. You could publish disclaimers regarding complex WHEREs making that slow to respond but at least it would work.
I mean the whole point of a rowset is to hide any virtualization or caching and allow you to conceptualize it as an in-memory query result. It’s acceptable to say the forward-only access without a count is faster, but not to prohibit it, if it’s in the API. Also, I’m accustomed again to .NET where you either have a DataReader (fast forward-only cursor) or a DataTable (whatever an underlying DataReader returns, completely loaded to memory so long as it doesn’t exceed 1.5G – the last documented limit I was aware of and which is probably higher now). This also provides freedom to navigate in either direction or any number of iterations, jump around or whatever. It also benefits from FoxPro’s acquired local cursor engine in that regard, just as Sql Server’s query optimizer incorporates FoxPro’s Rushmore optimization technology. My guess is the cumulative development effort and gravitas over the years, if you will, for this functionality alone is more than Xojo has been able to invest in its whole toolchain, life-to-date. So call me spoiled; I’ll plead guilty, lol.
I don’t disagree with anything you’ve said. Those of us that have been around for a while have built-up our own toolsets to minimize the differences. In some cases this means subclassing controls to adjust height or position for another platforms (don’t get us going on porting Mac/Win apps for Linux). Sometimes that means adding code in a window to do that. And sometimes it’s just ignoring the issue (like Xojo does in many cases). It’s all a matter of how much work you want/have to put in.
Many of us here have used Xojo for decades. The last 3 or 4 years (i.e. after API 2 was introduced) have been very challenging and a lot of us have moved on either by choice or by fiat from bosses/clients. In my former life as a consultant I’ve told all of my former clients to move away from Xojo for their own safety. Some are moving quickly and some aren’t. But it’s not my problem any more so they can either take the advice or not.
4 Likes
It is the price you pay for native controls. Something I don’t have with Java. Running on windows means also running on macOS and running on Linux. Even the Database connector is always the same while Java. But the controls are never native and the user experience is most better with native controls. Using them is not priceless, it is not only a problem with Xojo but with QT also. That is coming up with the need for native GUI behavior, nobody can change that. Sounds sad but…like always…smile, be happy, it could be worse.
1 Like
Differing sizes of the controls on different target is NOT cross platform. Maybe if the interface was responsive… But with fixed position controls, no way.
1 Like
Hal different component Sizes for native controls are normal. Exactly that is one of the problems where I decided that I don’t want that and write my code with Java Swing instead of Software like Xojo. While I have no platform differences and everything works like a charm. But. Not native and that not even a bit.
This would be my bias as well. There are “opinionated” frameworks that go for precise placement and sizing over native look / feel / behavior or with some small tips of the hat to native behavior perhaps.
I feel that since users have gotten accustomed to the Wild West of web apps, where things can be randomly styled by the app designer, and there is Electron and similar putting web apps into desktop windows, users have less rigid expectations for what a desktop app is “supposed” to look like anyway – even on macOS.
Agreed. There’s no rules about control attributes across platforms.
But how can Xojo be a cross platform tool if it cannot manage, at the minimum, sizing?
1 Like
Agreed
And I dont think there is any plan to do anything here
In theory “auto layout for desktop” might address this but I think it dropped off the roadmap (it has :P)
AH !
This would be up to the ODBC driver vendor to do something like this
Not sure MBS or Xojo are the vendor
They just use whatever driver the DSN configures - quite likely the MS one ?
You might have to take it up with MS ?
Does seem super odd that MS Sql Server cant do this without the right kind of cursor though
.Net does have decent APIs and it seems odd that MS, and their river, wouldn’t be capable of many of the same things as .Net
We’re you using ADO.Net ? or a different API ?
that was, at one time, where something like “auto layout” would help since you could specify positions etc relative to other controls
Something we’ve all written bags of code to do at one time or another because default control sizes are different
if instead you could have some nice easy way to say
- on windows keep the left of this control 12 pixels away from the edge of the window
- on macOS keep the left of this control 20 pixels away from the edge of the window
and it just adjusted itself (plus all the other controls) it might make the different sizes moot
but, I see auto layout for desktop has dropped off the list
Let me say:since I am using FlatLaf Design for Java Swing I have a closer to MacOS Design of my Apps than to Windows. But yes, Apps can be designed totally free like Discord and other Apps the have nothing to do with native Apps and I guess today many users are not even taking a look what kind of Design the App has. But many do.
I decided - while it was less complex for me - that I am going not the native way while I need to get every UI through the checks of the regulatory office and I have to write then for every UI a complete doc. With one UI I have exactly one time regulatory Affairs, one time Usability studies, one time documentation. Makes it less complex for me. But others having other Ideas.
good point but they can compile for many platforms so they call themself cross platform and people agreeing to it. Real cross platform is Java Swing with its own UI for all platforms. But if you want both worlds, native and XPLAT you may have to accept that it has a price.
It’s worked out so well for Xojo with iOS it’s not surprising it’s dropped off for desktop/web. Working with it on a client’s iOS app it’s okay once you’ve gotten it setup but adding a new control, or moving existing controls around on a view is not very easy or intuitive.
Yeah enabling it IN the IDE was, admittedly, a bad idea
Blame me for implementing that
It makes setting up a layout far too hard
Just turning it off in the IDE would make a world of difference to this
On .NET I’m using ADO.NET (and really that is underlying any other method one might use, such as Entity Framework / Linq for Sql – people sometimes confuse ADO.NET with the older Com/ActiveX ADO; they aren’t the same thing and have zero in common).
In Xojo I am using MBS sql plugin to connect to Sql Server via a system DSN (64-bit ODBC manager), 2-way cursors off, batch size 2,000. I would prefer native Sql client but that wasn’t speaking to me and Christian just went with ODBC, stating that MSFT recommends / prefers that in some way anyhow – which I’m not sure what context he was speaking in. IMO ODBC is this ancient thing I didn’t think I’d ever use again but since Christian wrote the driver and he seemed so comfortable with it and I wanted to get past this issue – I just ran with it.
Database handling with Xojo for xplat is a big beast. That’s never simple to do cross platform with Xojo. There is always something uncomfortable which architecture you may ever use