+1 on the point release.
I am now working 20 years in customer relationship business and trust me please, not fixing such issues in time will make more and more customers shift to vote with their wallet instead of words. 
I count this as a significant bug worthy of a dot release.
cant agree more.
this is a bug strong enough that I have de-installed 2019r1 from all machines (development & build machines). And all code bases that were upgraded to 19r1 have been returned back to 18r4.
I have had to start making this same shift.
This bug is severe enough and affects such a large group of users, that if a 19r1.1 is not provided, we should see license extension for anyone holding a license that included 19r1, but expired before 19r2 is released which includes the date of release of 19r2.
Same here - 2019r1 is out of discussion for any production tasks/builds. And as a side effect, 2019r1 is hardly ever used here (also for non production things).
And with many Xojo Developers (especially those with bigger/public projects) not using 2019r1 there is another “worse” situation: Regressions that may have slipped into 2019r1 don’t get uncovered. Once we report that during 2019r2 PreRelease they get “lower priority” because it’s not a “Regression in that cycle” (at least we’ve been told this at times in the past).
Yup… If necessary, we release multiple Bugfix Versions a week, and that doesn’t involve several people to work and focus only on that, neglecting other daily work. I don’t see how fixing, verifying and releasing one (or a handful) of critical fixes can’t be done off the last Release Branch - in a way that does not take soooo much effort that one tends to not do it. But I know… it’s not up to us to decide the strategy - esp. since we can’t see behind the scenes…
My thoughts on this: https://www.bkeeneybriefs.com/2019/05/listbox-celltextpaint-and-listbox-cellbackgroundpaint-memory-leaks/
If it takes that much away from other work then perhaps they have too few developers. No?
Well, Xojo is not saying that they will not do a point release:
I think, that even if 1 day of resources to release 2019r1.1 delay 2019r2 by a week, in this case, it is worth the time.
Even my program use listbox paint events and I’m not a professional programmer.
this is an important detail. Xojo/@Geoff Perlman havent said word (for/against) a point release. so we cant make plans of action until they make a release (either 1.1 or r2). besides rolling back to 18r4, I wouldnt make any drastic changes.
And that is something that I am starting to become nervous about. Previously, @Geoff Perlman would have checked in on a topic this code busting.
Oh I’m sure he’s read it, he’s currently working on documentation.
So at least the bug will be documented?
[quote=436800:@Markus Winter]So at least the bug will be documented?
;)[/quote]
2019r1 should have a warning on its download page. There are one or two very serious bugs and they’re not immediately apparent, nor are they documented.
You could say the same about 2018r4…
and a few others. Database corruption, flickergate, glacial styledtext are just a few that made releases unusable for me.
But that was predicted when they introduced the Rapid Release Model, so what did people expect? I got pretty much shouted down as people were eager to get their hands on new features - but what good are new features when they are buggy or the apps you build are of poor quality because of other bugs?
A Rapid Release Model is good for releasing bug fixes, but for features it is a disaster. Even Apple ditched their accelerated 12 month OS schedule and (to save face) turned it into a tic toc model with one release focusing on features, the next on stability.
The thing I feared most when Xojo introduced the Rapid Release Model is that it would get into a permanent beta quality state, and that would result in a bad rep that would threaten its survival. With bugs like this allowed to persist it isnt even beta quality, its unusable.
Good quality - youll always have a niche. But poor quality is not a good long-term survival strategy. Especially when you rely on customers who run their business on your product.
This is absolute nonsense.
For the rest I agree. The Rapid Release Model doesn’t work because the QA department of Xojo simply doesn’t exist. It’s pure luck if a release is workable for us users or not. I’m still on 2018r3 and don’t see any reason why I should even attempt to test for 2018r4 or 19r1.
[quote=436857:@Beatrix Willius] @Markus Winter: one release focusing on features, the next on stability
This is absolute nonsense.[/quote]
In all fairness it’s what Apple said about iOS 12; in that it’s primarily a bug fixing rodeo. Except that the annoying bugs introduced with Apple Music, are still there. Features they removed in iOS 10 (which I used) are still gone, Apple’s solution to the problem they created is to spend more money with Apple.
It exist. We are the QA Dept. 
That this has crept into the code base is just a very normal thing to happen and I don’t mind at all. What I don’t like so much is how Xojo is dealing with bugs like these. Just replying to a post on the forum is not enough. If I hadn’t, by pure chance, stumbled upon this thread I’d never noticed the bug. Now dropping a few bytes per listbox cell paint is not a big problem for any of my desktop apps, but I guess am just lucky and in general I am a happy 2019r1 user. What imo Xojo should do is actively notify its customers and tell them what’s up, and also of course put a big red warning into the docs.
No, it needs to be fixed asap. Would you buy a TV if there was a sticker on it saying “Please be aware that this TV must be restarted every few hours, because of an issue with the memory controller” ? Why is Xojo thinking it’s ok to sell a product with a serious issue?