Doing Xojos job with re-verifying bugs in new Feedback

Is it just that one case or are there others?

Hi @Bill_Gookin, I realize it is very frustrating for a case like this to sit around so long. This is of course the rare exception but I can still understand it being frustrating.

I just reviewed that case again and it continues to not be reproducible based upon the instructions you gave. Paul marked it as verified almost certainly by making assumptions about what you meant though he did not add those assumptions to the case. I didn’t make such assumptions and that’s why I closed it in 2013. After it was closed, it looks like Christian Schmitz added some additional instructions that ARE reproducible but they don’t match the instructions you provided and the case was already closed.

If the instructions Christian Schmitz provided are what you meant, I encourage you to create a new case.

What did I provide differently?

This case is perfectly reproducible in Xojo 2021r3 last beta:

dim i as intro

After the into type the tab and you get “dim d as Introspection.” and Xojo makes a point there, but it doesn’t make a point in auto complete anywhere else as far as I know.

Please reopen that case. If needed I can record a movie. I may even use iMovie to add some movie effects to underline the effect, if that helps!


Having us constantly create new ticket for issue just scatters the knowledge of the issue.

Like my 7 and half year old ticket where I had one more time to create new ticket because the tester was not reading the full ticket. It just makes no sense.

And the new ticket has nothing that the old one does not. Except once again the tester can reproduce it. (but thats same as in the past they always can reproduce it after they actually read) But then it waits another few years and again they wont reproduce because they stopped reading.

This is a problem of something totally different than your users having to constantly create new ticket for the same thing.


True… And we could use a much better/stabler way to add information to the cases even if they where closed it could be really useful to add info.

Rare exception, funny how I can instantly think of another case, there’s probably more:


then mentioned and subsequently confirmed separately on the forum in the channel you specifically set up for us to address issues like this:

1 Like

This does NOT seem like an exception. Just one example, My FC 51841, This is not an IDE problem, it is a BUG that affects the GUI of compiled apps, even some new users could test Xojo and say “if my apps will look like this, lets find another tool”. It had videos, samples, input from other users… It was closed and almost 4 years later with the latest release of xojo, the list boxes still look awfull when the user needs to do a horizontall scroll.

Yes, there is also a new FC just for telling xojo that the bug is still there even when the original case was closed: 66442

As Björn says, users are forced to to constantly create new ticket for the same thing. But doing so is not a guarantie for the bug being fixed. How could you not see why users think that it is a waste of time?

Obviously there was some miscommunication about what exactly was being fixed. I’m quite certain most users are not entering their cases multiple times. I know it can be frustrating sometimes @Ivan_Tellez but we are human beings trying to make Xojo the best we can day in and day out. So we will make mistakes and you will make mistakes. If you think something has gone wrong, reach out to us. That’s what we do when we feel we are missing information for you or any other user.

Honestly, I question the need for your own customized bug tracking system. Don’t get me wrong, it is kind of cool to use Xojo to do stuff like that but you have to admit with a very small development team it seems like a waste of time to reinvent the wheel considering there are a number of free or low cost bug tracking systems available that have thousands of man hours of development behind them.

You say creating your own gives you better results. Evidence suggests otherwise. You keep trying to reinvent something better when perhaps you need to change your development practices to match what a real bug tracking system can do.


In the past when we considered it, we were not able to find something close enough to our needs. And our experience trying to clobber documentation into a wiki suggested we’d spend just as much time trying to force something else to be what we needed.

Today, there are still challenges. If Xojo were to pick something off the shelf, I think the beta group, case privacy, and feature request ranking would be the biggest challenges. Most issue trackers are tuned well for bug reports, but no so great for feature requests. And I’m not aware of any (though I’m not up to speed on the current market) that offer something more than upvote/downvote ranking.

I mean, the FogBugz era didn’t last long at all. Any SaaS option won’t be customizable, so they’d need to host something. That means modifying code, which also makes updates exceedingly difficult. I’m not convinced an off-the-shelf option is the best.

I prefer to use the new feedback system developed in xojo because of only one reason. It will make Web 2.0 much stable as they will use their own system.


That’s a mighty big assumption.


I learned today that it’s possible to use GitHub Issues with a private repo. Xojo could in theory have a private GitHub repo for their source code and a public issues repo. They are linked together but GitHub cleverly hides data leakage between the private and public repo.

GitHub’s issue tracking system is really nice.


@GarryPettet : this is not a reply specific to your post, but a general comment on the whole thread.

This thread shows how passionate Xojo users are with the product, and how Xojo is important to our own business. There are however a few things that we seem to have lost perspective of:

  • Xojo is a private company. They are in their absolute right to use whatever tool they see fit for development and operation, just as we do in our own business.
  • I would expect that Xojo management and engineers are well aware of various tools and options available on the market. In this context, we must assume that the decision to make their own issue tracking tool must be well justified. I would not go down a route that costs more or provides lesser results when my business depends on it. I expect that most everyone on this forum would not either. Whether we think they are right or wrong in their choices is irrelevant.
  • Our place is not to design the product or the tools for Xojo, but to use what they provide. A corollary of this assertion is that if we are not happy, we can move on as others did. Moving on is not something to decide lightly. The bigger the code base, the more expensive the move is. But, this is what customers do in a free market.
  • First releases of a product are rarely as complete and as polished as one would like or expect. Case in point: Web 2.0. I was extremely disappointed with the first few releases. It took the better part of 2 years to gradually get a usable release for me and my use cases. 2021 R3 marks that point where Web 2.0 is good enough to go productive with it (for my use cases). I expect Feedback will go through a teething period just in the same way. Hopefully a much shorter teething period. :wink:

So, where am I going with this? We obviously are a bit worried with the coming changes to Feedback. Rightly so. But there is a line that we cannot cross and some posts in this thread come very close to crossing that line. I for one, will not tell Xojo how to run their business, but I will not hold back if the product fails or the feedback tools and processes fail once the change is implemented. Customers can voice their discontent with products and services, or even move on if things are just too bad. But customers cannot run the business in lieu of the company.

My 2 cents on the whole thread.


I’m not saying that Xojo shouldn’t rewrite Feedback with Web 2.0. I suspect overall that will be a positive thing since they will be dog-fooding Web 2.0 themselves which surely will only improve the product.


Well, at the moment they can’t build the new Feedback with web 2.0 because you can’t build large & working web apps :)) so… it will take some time

The dog fooding is important here.
The WebListbox, the session handling and all the JavaScript must be rock solid, before you put such an app out, which would see hundreds of people using it.


I’m not sure where you got this impression, but the delay has nothing to do with the viability of Web 2.0.


That’s very true and it would also be a good showcase for web 2.0 which is a good thing imo.
Is there any ETA for the new Feedback?

Web 2.0 is in pretty bad shape still - for example, 2021 R3 was released even though WebListbox sorting is completely broken: