Listbox.CellTextPaint and Listbox.CellBackgroundPaint Memory Leaks

There are bugs and then there are bugs.  Not all are created equal and certainly not all are worthy of a dot release.  But when a serious bug comes to light you have to take it seriously.

Feedback 55596 is a perfect example of this.  If you use Listbox.CellTextPaint or Listbox.CellBackgroundPaint your app will leak memory.  Leaking memory is bad to begin with but since the Listbox calls these events frequently.  Losing 64 bytes per call adds up quickly.

I was going to do a release today for a client using 2019 R1.  This was the first release where Windows drawing was as fast as older versions of Xojo.  Prior releases of this product had to be built with 2017 R2.  So now what do I do?  I’m damned if I do a build and I’m damned if I go back to 2017 since we have to retest everything.

Xojo Inc. doesn’t seem interested in doing a dot release.  On the forum Greg was quoted as saying, “…doing a point release is not an insignificant task and takes resources away from making progress on other things, never mind the additional stress that comes with it.”  Who cares if it’s work on their part?  Seriously, if I can’t use the current public release then why am I here?  It’s bad enough I’ve been chasing Xojo versions for nearly two years with Windows drawing.

This is part of a much bigger issue that many at the Xojo Developers Conference discussed a few weeks ago.  Xojo has always been a lean organization and many times I’ve felt that it’s been quite anemic.  But an important bug and a public release to fix it shouldn’t be a major stress inducer to the developers.  To me this says there are too few developers and too much work on their plate.

For what it’s worth, the bug is marked as fixed as of May 14th.  It’s still too early to tell if we’ll get a dot release for such an important bug fix.  Maybe R2 is just around the corner but I don’t have time for a 30 to 60 day beta period.  I need this fix now.


19 thoughts on “Listbox.CellTextPaint and Listbox.CellBackgroundPaint Memory Leaks

  1. This kind off stuff makes me worry about Xojo INNC … I doubt they really think they are “rightsized” engineering wise… but maybe they are by financial situation? If so that would be even more concerning..

    As far as we know they have not really replaced Joe or Norm, but just made existing staff wear more hats… which besides slowing things down, that pressure would tend to ensure more bugs will likely get introduced…

    Even if they do hire one or 2 more enginners, we have heard how long it takes for someone new to come up to speed on the code base… that does not bode well for the next year at least.

    • Even for our type of work I figure it’s *maybe* 3 to 4 months before I trust a developer to do client work. With a project as large and complex as Xojo I would figure 6 to 8 months before they’re comfortable enough to work on the IDE without screwing something up by accident. And that’s assuming the Xojo developer is actually good at coding.

      So yeah, it’s concerning. The “we’re doing fine with the developers he have” message doesn’t resonate well with me.

      To be fair though, have you tried to hire anyone with Xojo experience? Those are unicorns. So then you risk trying to teach someone Xojo and who knows if that’s possible.

      • Norman comes to mind … 😉

        … or Julien. You get the feeling he could teach Xojo a thing or two about Xojo … 😉

    • Personally I’ve felt, for a very long time, that Xojo havent had a “adequate level” of staffing in years
      They should have
      – windows framework guy
      – linux framework guy
      – macOS framework guy
      – iOS framework guy
      – web framework guy
      – compiler guy
      – IDE guy
      But they don’t. So many people did, and still do, wear many hats and that has a cost in terms of expertise, speed, testing, moving frameworks to newer technologies, etc.

      • And besides all that an engineering manager (separate from CEO) that ensured it all comes together in a consistent way with good quality …

        But I fear it is all a matter of money… that Xojo’s paying user base may just be too small to support a more extensive engineering staff at the income level the company wants/needs… (good IT people are not cheap)… and that concerns me.

        The lack of resources to keep up/ modernize and improve fast enough in this fast paced marketplace may also be causing a chicken and egg problem in terms of attracting new paying users for the product.

        – Karen

  2. I’ve thrown my hat in the ring several times at Xojo for a job but it appears they really aren’t looking to hire at the moment.

  3. It is concerning. The company, even with the Norman and Joe, seemed to be resource constrained. It almost seems like a catch-22 slow death; Not enough revenue to hire more employees to improve product quality and features, but can’t get new customers and retain existing due to poor product quality and features.

    Why did Norman leave? (no flame war intended).

  4. Travis from the Xojo forum said this:

    “We had indeed already made a fix for the Listbox case being discussed here – that fix, as well as some others – will be present in a point release that will be available for Pre-Release testing shortly.”

    • I just watched today the session video from Yousaf’s XDC session about happy customers.
      Maybe the Xojo team can watch it soon and figure out what took so long to respond to this. (assuming they were working and not on vacation or sick)

    • I fully believe that they had already fixed this serious bug. But note what Travis didn’t say. He does not say that they had planned a point release. I think that only came about because of the stink raised.

  5. I think xojo have tried to juggle too many balls. With the benefit of hindsight they should have just restricted themselves to desktop and concentrated on excellence in that.
    I think you’d get more people prepared to pay for user friendly, niche and slick with stuff like umm grids, than for something that promises the sun moon and stars but constantly fails to deliver on that.
    Since I’m desktop oriented that could just be my bias coming out. I don’t do any web and the mobile stuff I do is with b4x which is a pleasure to work with imo.

    • Oh, I dunno. We go in streaks of desktop or web projects. Some years it’s 80% desktop, others it’s been 80% web. I have no rhyme or reason why it fluctuates so much. We’ve done a few iOS projects for clients and we’ve had to turn some away because we can’t do Android.

      But I also realize that I’m a rarity in the Xojo world where we do so many different projects on so many different platforms. I can’t argue with you on needing a nice grid for desktop (even though the built-in listbox is pretty powerful once you get to know it).

      • Very interesting, Bob. When you do have calls for these different platforms is it that the client wants the same app for multiple platforms (desktop, windows, macOS, iOS, Android), or, do they just want an app for one platform (mobile)? Are you developing the iOS apps in Xojo?

        I’ve always felt they are spread too thin to support all these platforms successfully. To me, I would have forgone the iOS and Android markets in favor of WEB and Desktop. Now, that is counter where the industry is going, but hear me out.

        There are millions of iOS/Android apps on the app store already. Those all had to be developed with something. Those development platforms can’t be that hard to learn based on the sheer volume of apps and the price of these apps (many free). How much is a guy going to spend on a development platform that is going to give away the app? That market is already heavily entrenched and well served. XOJO being years late in that market is going to make it nearly impossible to penetrate and at the cost of their other products. Result? Existing customer erosion due to poor quality and no new adoption.

        To me, the money is business apps which are desktop and web. Sure business’ need mobile apps, but XOJO now and in the immediate future is probably not the right tool given its state.

        If XOJO focused all the effort in WEB and desktop that they spent on iOS and now Android, imagine what kind of product we would have. Imagine what customers would pay to rapidly develop business apps that make their organizations money. We use XOJO at our company, it has done amazing things for our operation. Coming from a business side, the product is too cheap and they are marketing completely wrong. Their marketing caters to the hobbyists and educational instead of enterprise development, where the money is at – especially web development, which is by its nature should work on mobile. But the web is not quite ready for primetime. The desktop is o-so-close and iOS and Android are still unbaked. I would pay more for Xojo, but I don’t have too. If I pay more I would expect more, but it would take much to get more of my $$$.

        Sorry for the rant.

        P.S. I always enjoy your blog posts and thoughts on consulting/development. Keep up the good work, and fight in some cases, :-).

        • I’ve felt for nearly 20 years that their focus on the citizen developer market was a wrong approach. Citizen developers can’t pay for much whereas a business environment doesn’t have a problem paying extra for extra features. I came from the VB6 world and we used to spend $3-5k PER developer for 3rd party controls and libraries. It’s significantly less expensive using Xojo.

          • Enterprise site I used to work at had 400 devs and each had virtually everything available for purchase at the time from the 4D world
            Every add on. Compilers & everything.
            The budget was something like 4K per developer per year. Just an expense to support running the business.

            Thats a LOT of citizen developers to make up the same revenue.

Comments are closed.