Shouldnt need to petition for upvotes for such a bug but

Agree. Once I reported a bug and it has been duly identified as reproducible, the ball is in the vendor’s camp. If it comes back to me after a period with a tag saying ‘we did not take care of this, go figure yourself if it still matters to you’, we definitely have an issue. After all, it is a commercial product with a price tag.

One reason I dropped my former development platform is that too many bugs got either not fixed or it took many months.
To Xojo’s honour I must say that at least there is a public bug list and devs can research that list.

See, as I am coming from the Java World I do not know that situation. So far as I can remember I had always fast Bug fixing. And starting with OpenJDK I could also fix by self and place a commit. What drives me crazy is that with Xojo you can only pray that there is some workaround. If not: show stopped. And exactly that is unacceptable. That is something Xojo should fix immediately. Like I wrote on TOF: there would be a good way in changing the release cycle. Bringing two release lines, one with new functionality, one production ready release.

1 Like

Depends on what your name is :stuck_out_tongue:

That has been my experience as well.

Bot auto closing VERIFIED BUGS ???


Autobash is the new fixing

1 Like

thats a good name for it :stuck_out_tongue:

1 Like

Geoff : Hey team, we really need to lower the number of bug reports!
MVP : Hey Boss… I have an idea, and the Xojobot can do it for us!

1 Like

Yet they have feature requests that have sat there for 14 years with no action

Makes no sense

If in 2 years you haven’t touched a VERIFIED BUG then thats not my fault
Thats bad planning, organizing, and prioritizing in their part

guess I need a bot to just go update all my reports with “uh?” or something every once in a while :stuck_out_tongue:

This raises the question, why bother? It will probably still sit there being ignored.

This is part of the meaning behind my statement that I can’t help Xojo, if they don’t want help.

It looks like another one of my customers may have found a bug in the Xojo GUICocoa.plugin, but what’s the point in writing up a report and providing Xojo with a sample application. We’ll have to find a workaround anyway, so why spend that extra time trying to do the right thing, when it’s not really wanted from either end?

There are days I ask myself this
I suppose Its the right thing to do ?
But yeah some of my old reports that still happen & have been archived I’ve just shrugged off as “Myeh”


I just added “Another one closed, another one closed, another one closed by the bot.” to the reproducible bug report which the bot just closed.

At this point, I have absolutely no interest in filing any more feedback with Xojo.


Those are, IMHO, unforgivable
Someone went to the trouble of filing a report
Your staff verified it and marked it that way
And rather than deal with it it just languishes until it gets closed

I’m not going to say it was perfect when I worked there
Far from it
I know we had some that sat for a long time without movement (for whatever litany of reasons)

But a reproducible bug should never be closed this way
Feels too much like “yeah its a bug but we just dont care so thanks anyway”


I also stopped reporting and there are things to report (ref.documentation).
Have also stopped working with Xojo as I do not have any Xojo-based legacy code to maintain. And my appetite for risk is not that big.

What you will use instead (only while I am personally interested)?

Looking into Swift right now. I do not have to produce Windows apps.

1 Like

Need to get @DaveS to show you his Swift framework that should make moving to Swift from Xojo easier

He wrote some tutorials on it
see Swift for Xojo Developers : Introduction - #5 by DaveDuke
Swift for Xojo™ Developers (cont'd) : SCREEN
Swift for Xojo™ Developers (cont’d) : RANDOM - #2 by DaveS
Swift for Xojo™ Developers (cont’d) : SYSTEM


I think there are 13 of them so far
and when I get the chance I’ll write some more

Right now the framework (not yet released to the public) is part of two major projects

  1. Xojo2Swift - a proof of concept app that takes a Xojo XML file and creates an Xcode project. It attempts to translate the Xojo Code to Swift and is about 80% accurate. The GUI it does like 99%

  2. RAPID (name to be changed later). This is a self contained IDE the will include the functions of Xojo2Swift, but will also be a full drag-n-drop interface of its own. The name RAPID originally stood for “Rapid Application Prototype : iOS Devices”… and I do have a verision that does the GUI part for iPhone/iPad

1 Like

Now that’s interesting!

here is a list of links to all I’ve posted so far