Xojo bug handling

Kind of split this from Realistically, what could Xojo do to make you stay? - #209 by samRowlands

This might seem crazy but since there’s a widespread belief that bugs just dont matter and get swept under the rug is there something that Xojo could do to counter that perception ?

Would a bug bounty program matter ?
Something to demonstrate bugs ARE a priority
If a bug gets verified the OLDEST report of it, if it has duplicates, gets the credit
And those credits can be used to obtain a discount ? if you get enough you get a free license ?

Thoughts ?


transparent process!

Explaining how they are internally addressing bugs! I don’t care about how they would do it, but transparent and with a life time longer than their next post. And every bug matters, I am upset by this “mark your favorite bug right now” only to see a few weeks later that it was again a loss of lifetime. I can’t remember how many of those calls I have seen in the past 2 decades …

Many users have said in the forums that they dont file reports because it feels like a waste of time, maybe this could improve that
Why do you want more reports if xojo is not fixing enought of the current ones?

What I said in the other forum, Xojo needs an extended bug bash. but, they got offended :rofl: :rofl: :rofl: :rofl: :rofl:

I also said that if they did rise people expectations with that short bugbahs just to leave most of the nominated bugs there, It was just going to reinforce the belief that xojo doesnt care for bugs, users and their issues. And here we are, with the widespread belief that bugs just dont matter and get swept under the rug. :man_facepalming:t2:


In the past, it was waste indeed, as the FC app regularly crashed. Okay, now they finally have a better tool. I have no active license so never used it. In the past if you had an open FC, the process of getting informed happened randomly, sometimes you got an email, sometimes not. Asking for more information is right, but sometimes you can’t even share code privately, as you would need to share confidential information. Not sharing more information almost always lead to an auto-close.

Giving feedback on urgency of bugs from others for myself only makes sense, if we are talking about a few bugs, let’s say < 500. The Current overwhelming list of bugs (some over a decade old) …phww, exhausting. A problem for Xojo but as well a problem for users. I had register for the new service, when my license was still active, and mainly got messages that bugs were auto-archived …

Agreed they have a serious perception issue that bugs dont matter

Geoff can SAY whatever he wants but look at how they act
And their actions indicate that bugs dont matter
Archiving reproducible bugs ? → BUGS DONT MATTER
Bugs sit for years and years ? → BUGS DONT MATTER

Say whatever he want they ACT like “bugs dont matter”
Maybe a bug bounty that worked would change that perception ?


The trouble is, Xojo’s bug handling is a symptom of the actual problem.

Lets be fair here, we all have to triage bugs, even if your not aware you do it, you have to do it. Xojo has far more customers, so they HAVE to do so. Heck even Apple with all their cash can’t triage bugs right to benefit customers (bugs are actually used to push people to update devices).

The trouble is instead of using engineering resources to retain experienced developers who have less voted bugs or feature requests, Xojo poured those resources into 2.0 everything, which in result created more bugs, broke apps and destroyed resources available for new customers.

I don’t believe that Xojo took that path without having any clue as to the ramifications. If they really had no idea how much it would piss off the community, they’ve doubled down on it, almost saying “This is the way, if you don’t like it, there’s the door”.

What upsets me the most, is if Apple break my apps and I need to update my copy of Xojo, I have to re-write my apps in 2.0 everything to take advantage of “bug fixes” and new features. A lot of time wasted by Xojo and me, just so I can give them more money.

I think the best bet for the long term is to move more and more of my apps into a different language and reduce my reliance on Xojo as I simply cannot trust that they have my interests in mind. I am seriously concerned about the longevity of the company. I don’t think they’re going to close down tomorrow, but I do think they’re on a death spiral and the more they push customers away in the hopes of attracting new customers, the more they’re going to delay the inevitable.

What would be good, would be to contact those who’ve not renewed since 2.0 everything and ask what can they do. To contact the companies that have recently announced the migration to Electron and figure out why. Then act on it. Merge API 1.0 and API 2.0 (could be done by the compiler) so you don’t need to screw projects over and shit keeps working, while getting bug fixes and new features.

Basically undo 2.0 everything, focus more on keeping enthusiasts in the community. Let them promote Xojo and show the world what high quality apps can be made with the tool.

But there’s a reason why I am not a CEO with a handful or employees.


Th truly truly sad part of API 2 is that 99.9% ISNT compiler related at all and the API1 and API2 is very likely the exact same code in the C++f framework

The ONLY thing that has changed is the exposed API users see

Imagine it this way
You have a DLL
You write a class that has a set of declares into that DLL
That’s API 1
The exposed API is the Xojo code you wrote - not the declares into the DLL

Now some time later you release a new version
And it has a new Xojo API, but still has the old one as well - you just marked all the original ones Deprecated
But the declares your “new” API uses are the same ones as always - just behind new Xojo method names
Thats API2

More or less this is API1 and API2 for Xojo

Which is what I believed also, yet they’re fixing bugs in API 2.0. Which makes me wonder if it more than that.

Like the Date class has a bug in it, which is fixed in the DateTime class. Trouble is total seconds isn’t compatible, which means you have to add performance degradation conversions to upgrade. I’ve considered simply removing the Xojo Date class and using my own, which uses NSDate and NSDateFormatter underneath (which I am sure Date and DateTime use) but exposes more of the OS provided functionality that Xojo doesn’t care about, but I do. Sure it’ll have to have the same conversions, but in result I get more functionality and don’t rely on Xojo to get bug fixes.

Edit: Lets not forget that the DateTime class uses a whole host of new API that isn’t compatible, so I need to re-write code everywhere I’ve used the Date class, just to get the bug fixed. Which sucks, and I run the risk of running into other bugs, that won’t get fixed.

I think the DateTime class is repackaged from the deprecated Xojo.Framework… So Not API 1 but basically still pre-existing code.


1 Like

It takes time and effort to file a bug report. I have filed two. In one case, in line one of the report, I stated it was Postgres-specific. The tester put together a sample project based on my report, using SqlLite. Couldn’t repro the bug. “Oh, I didn’t realize it was Postgres”. Not an auspicious start. Then he asked ME to modify his test project to demo the bug.

On the second bug (requesting column info on a table not working) the same guy tried to argue that it wasn’t really a bug despite that the method claims the table has no columns. I mean in what universe is getting back no data when you ask for it not a bug?

I also noticed at this point that some of the other Xojo users seem to be so used to this that it’s almost like Stockholm Syndrome. People were guessing what some secret trick might be to get it to work. People, it’s a bug, just fix the blasted thing. Nor does it really handle error conditions correctly. If you tell it to return column info for a non existent able blargh, it just returns an empty rowset – so now you can’t tell the difference between a table that doesn’t exist and a table with no columns (which is possible in Postgres). It should throw exceptions when there are … well, exceptions. It doesn’t seem to be aware of Postgres schemas, so unless your table is in the public schema, as far as this function is concerned, the table might as well not exist.

In the end I just said look, I’ve documented the problem – both a bug and poor documentation actually – and I have an acceptable workaround in the meantime so mercifully it’s non-blocking for me (I just went straight to the Postgres system tables. If you want something done right … do it yourself. Took me 5 minutes, which was a fk-ton less time than reporting the bug). The bug is marked Reproducible. At this point, either fix it or tell me I’m full of crap, but I have used up my bandwidth for this about 3 times over and am not going to discuss further.

So … not only do I have the sense that I have to jump through rings of fire and eat little pieces of glass just to get to square one with any bug I might consider reporting, but both of these bugs, especially the second one, seemed to me like something that should be fixable in a few minutes for someone familiar with the source code, and in a lean little company with some pride in the product it could have been pushed out in R3 or at least specifically scheduled for R4. But I have the feeling it’s just going to sit there forever. One reason might be that these bugs have a certain smell to them … the smell of a leaky underlying abstraction or possibly incomplete work on the supplied Postgres driver. To really fix it might involve more than appears because it wasn’t properly implemented to begin with. Maybe the root cause of the Postgres issue leads to things that need review and more test cycles for other supported DBs. And maybe they’ve given up on DB independence like this function seems to represent, and are leaving it to MBS. IDK. Too much of a headache. Just hope it goes away, that’s easier than fixing it properly.

Anyway this is my roundabout way of saying that what would float my boat here is to take the effort to treat bug reports with great respect, quickly and systematically work through them and get them fixed in the next release cycle or at least the following one, every time. NEVER let them languish. NEVER have a silly “bug bash” and don’t even fix all the bugs accepted into it, and then act like that’s some kind of accomplishment when you still have a huge backlog of bugs, including some that are years old.

A bug report represents a failure of the product already. If users have no confidence in the process of reporting and getting bugs fixed, then it’s a triple failure: the original bug, failure to fix it, and disrespect for the value of the time of users who are also BTW paying a fairly pricey subscription to use your product.

(I understand users sometimes consider something a bug that arguably isn’t, and that bugs have to be prioritized. But it’s a failed system if it treats reproduced bugs as, meh, let’s just leave it in there. It’s okay if things are broken. No. Just no.)

ETA: I’m not inclined to file any more bug reports. And maybe that’s the whole point of how the system works. In fairness … neither bug was a show stopper and in general things work fine for my simple test use case of a single desktop target for what amounts to a glorified CRUD app. But if Xojo doesn’t care about anything but show stoppers then I will not report anything but show stoppers [shrug].


If they’d just fixed the bug in the API 1.0 class, I would have happily renewed my license and carried on.

Date is definitely old
But DateTime isn’t timely new either - its from the Xojo framework (Xojo.Core.Date I believe)
So there are in fact two different underlying C++ implementations

1 Like

Many good posts here! It is refreshing to see that my perception of things is shared by a good number of people who are more experienced coders than me.
Factually closing confirmed bugs (even when it is called ‘archived’ it is closed aka no plan to work on it) after 2 years of not taking care of it is a clear case of contempt of customers, who invested time and effort to report. @bgrommes laid out how this is implemented and how some people got to live in a universe where bugs are fine and handling them how it is done there is a clever way of doing it → Stockholm Syndrome.
Would a bug bounty help?
Honestly, I don’t think so. Before anything else, a change in corporate culture must happen. Without, no other sensible and meaningful change will ever happen.
The situation is biting those who have invested in a Xojo-based code base and products.
All others can take the way bugs are handled as a cautionary tale.

The devil’s advocate:
The ‘Pro Plus’ license is advertised as you can get faster report verification and faster bug fixes. Which means you can pay a lot more for improving the likeliness of your bug getting fixed.
Why not improving this business model by making all bug fixes payable? The rationale: if no one pays for it, it really doesn’t matter to anyone, why fix it then?
And even better: only owners of a valid license can file bug issues. This will make people buying licenses because they want to file bug issues.

1 Like

Many years ago, I came to understand Geoff’s lack of concern for the quality of his product and his lack of interest or ability to provide the resources necessary to develop and maintain Xojo (both the product and the company). Too often, I discussed a programming issue on the forums/mail list with Xojo / Real employees that turned out to be a product bug. Rather than saying, “Hey, that’s a bug, I’ll make a note of it and see if we can get it fixed,” the discussion would always proceed to “Hey, that’s a bug. You need to file a bug report”. At least once, I pointed out that, as far as I was concerned, I had just filed a bug report. Then I explained that if I ran such a company and discovered my employees walking away from information detailing a bug in my product, I couldn’t imagine how pissed I’d be. My point isn’t about the employees directly; instead, the employee’s consistent inactions revealed the culture their leader set for his company.


The August Removal Bugs were released on Mid-October…
That Xojo version Release Notes are presented following no order… (bug #, maybe ?) In other words, “New Features” are to be searched inside the list of bug removals…

At each new release, you can less and less use old project in the new version: New Desktop Controls are available only if you create a new project using 2021r3 and 2022.

Inter Ops entry in the Roadmap disappears…

Navigation bar rewrite also disappears (if it was in the Road map).

Seriously: no more talk, acts. And maybe sales will increase.

In short: I wasted my time.

Yeah. Here’s the roadmap as listed on May 18, 2022:

And here it is today:

Only 4 of the items from May are still there today (maybe 5 if you consider “Easy Database Connectivity” and “DatabaseConnection class” to be the same item - I’m unclear on it). Only 1 of those items were implemented - the others just disappeared as Emile stated.

No planned release dates given, no commitment to nothing. Don’t hope for it, surely don’t rely on it. This is how Xojo ‘manages’ their customer’s expectations.
Hundreds of thousands developers are puzzled. :man_shrugging:

They launched a release with the new event names in the old controls that was a comple fuck up and had to be retired despite many users told them exactly what was going to happen.

It looks like a Hubris Syndrome case, someone has no clue at all what people want/need but it feels like he knows better than anyone else and who ever disagree is just a troll.

That is like accepting he was wrong…


We know better that you do what you want :slight_smile:

Or Smartest Man in the Room syndrome

Hard to know which some days

Troll :stuck_out_tongue:

1 Like

I know I have participated and vented some frustration here with the lack of support from Xojo that I’d liked to have seen, but reading this thread is so sad for multiple reasons.