Is this you as well?

I’ve had conversations with several other Xojo users who have said they stopped filing bug reports for various reasons.
Is that you as well ?

  • No. I still report bugs to Xojo
  • Yes. I stopped reporting them

0 voters

If fairness, I don’t conform to a binary 0/1. If I am able to work around the bug, I sometimes don’t bother. I am unable to do so, I do report the issue.

1 Like

Same here. If it’s a showstopper (for me), then I’ll report it, or if it’s something simple like a docs error. Otherwise, it’s just not worth the effort to research and report everything needed to make it an “acceptable” report, especially when it’s likely to just languish like most others anyway.

1 Like

Both good points
I probably should have had a yes
“Sometimes : please explain” choice

1 Like

Most of the time I can write something in C++ as a workaround, or create something new entirely, or write it in another language, or create a plugin. I don’t usually report the bug unless its something easy to be implemented. If it is a challenging bug, then I won’t report it.

1 Like

I stopped reporting the Xojo crashes. Those are mostly pointless because I can’t reproduce most of them. What use is a crash log if the developers don’t do anything with it?

For the bad bugs I get Christian to make me a workaround.

1 Like

Well, I do have a lot of feedback cases.
See my blog post Xojo Feedback Success rate

About a quarter of my cases got fixed, completed or resolved.
Xojo Inc. is a small company and you may need to lobby to convince them, that it’s not just a problem you have, but a wider audience.

I don’t report every issue.
When Xojo crashes, it’s useless to report this.
You will be asked for more information within 10 days, but it’s always impossible to reproduce these bugs.
Bugs that I can reproduce, I do report them with a small project or sometimes a video as help.
I tend to believe that they are reviewed and confirmed and then most of the time forgotten or Xojo is not interested in solving this bug.
I also believe it’s even worse when the bug is a specific European/non American problem like komma and thousand point.

I also will not report the Xojo crashes.

If I can quickly create a test case for something I encounter, I will report it. If I cannot quickly create a test case, I will try to find a workaround. If I cannot find a workaround, I will refactor my code. Basically, I have given up and do not believe that Xojo will fix bugs that affect me. When they do, it is a surprise.

This IS indeed nuts
I have 100+ reproducible cases - ones where they already have a means to see the bug in action - that have had no action

That we have to lobby to get those fixed says there’s a broken process in place

I cant reply to your blog post but here my numbers (just since I left 18 months ago)

closed already exists      5  0.96%
closed by design          33  6.36%
closed duplicate          23  4.43%
closed misc               21  4.05%
closed not actionable      3  0.58%
closed not reproducible   30  5.78%
closed wont implement      6  1.16%
fixed and verified        72 13.87%
implemented and verified   8  1.54%
needs review               5  0.96%
reproducible             114 21.97%
reviewed                 158 30.44%
verified                  16  3.08%

Likely so, but that is IMO a refection of management priorities combined with lack of sufficient resources forcing a brutal triage processes…

I suspect how it works in practice much of the time,is if the fix is both obvious and quick and an engineer is working in that code already , AND is aware of the bug, it might get fixed… but Engineers already have so much new stuff on their plates…

Otherwise the bug has to be viewed as a MAJOR showstopper without a workaround for the majority of users for management to prioritize fixing it over working on new stuff.

I may be wrong about that, but it sure seems that is how it is.

That is not a way to create a product that can be depended on, never mind be an efficient RAD tool…

Many times over the years the RADness for me got significantly hurt by the time it takes to figure out workarounds to bugs.

Not being a pro, declares are often not practical workarounds (unless someone else wrote them) as there is usually too much to learn to use to figure out how to do it, never minding having to do it for each platform as well…

Not having to know all that stuff is why I use Xojo in the first place!



Looking at other IT companies whose products we use at work there seems to be a very different mentality. Those companies fix EVERY reproducible bug we report within a month maximum. When we pay for a product then we actually are paying for a set of features. So for example if we pay for the feature „reporting“ then we expect that the the software can produce reports reliably. There is no discussion or lobbying required to get bugs fixed: If the customer paid for that feature, that feature has to work exactly as promised.
That is all I expect from a software that costs money: All features listed in the product description (= features the customer paid for), should work perfectly. That is simply a question of honor for these companies. B.t.w. they make advertising with customer satisfaction.

Some time ago I watched two presentations of Java developers. They were developing applications for an insurance company and a bank and both teams were developing those huge applications for 3 years. Could you develop such a huge application in Xojo? In theory yes, because all features needed are already there or available via plugins. But then reality comes in where Xojo struggles to deliver a bug free „Currency“ datatype for years.


That’s also my feeling, that resolved bugs aren’t the one affecting me.
I’m now starting to wonder whether they fix bugs that are affecting anyone… :thinking:

I’m number 3: I mostly stopped reporting them. Sometimes I add additional info to someone else’s reports. I feel deluded reporting things that usually:

  1. Gets a status of “needs review” forever, and the bug will be retained there.
  2. Gets a status of “reviewed” forever, and the bug will be retained there.
  3. Gets closed using some lame excuse, and the bug will be retained there.
  4. Receives an insane question like “did it exist in the past? If you don’t answer it will be closed in 10 days” that mostly will make the report closed and ignored, because you don’t track unquestionable things unexpectedly being questioned. And the bug will be retained there. (My answer would be “I don’t know if it existed in the past, I know it exists right now, I do expect someone checking it and fixing it”).
  5. A lot of other “We don’t have time to fix it, so whatever…”, and the bug will be retained there.
1 Like

What’s the difference between:

  • fixed and verified
  • implemented and verified

and also

  • reproducible
  • verified

I was keen enough to post bug reports at the beginning and even was encouraged when Xojo wrote back, asked for more information, and in a case or two, actually verified the bug.
Then, they sat for years, never getting fixed, so I figure it’s time I stopped beta testing their product for them for free if they weren’t going to do anything with the information I gave them.

What’s sad is I literally have to BEG my users to give me feedback on my software, and almost never receive any sort of reports on bugs or anything else, negative or positive. Here’s an amazing group of built-in free beta testers that most companies would kill to have available to them, and they squander this free resource. Baffling.



  • fixed and verified - Bug fixed, QA guarantees.

  • implemented and verified - Feature done - QA assures it’s ok.

  • reproducible - Bug exists, occurs following steps reported.

  • verified - Bug exists, we saw it.

1 Like

Thanks, @Rick.A. The first one makes sense, bug vs improvement/feature, but I don’t understand the difference between the 2nd two. If Xojo marks it as reproducible, then how can they have not seen it?

Some kind of bugs are only found when some circumstances are met, without them, it does not show up. Maybe Xojo use this status to differentiate a bug triggered every time (like clicking in a text field causes a crash - Verified) than a bug hidden needing a combination of factors (like clicking in a text field causes a crash IF we have typed the number “9” there, wait 3 seconds, and then click there - Reproducible).

I agree with all you said, EXCEPT the mention of “QA”… not sure Xojo understands that concept