Xojo 2019 Release 3.1

Last week Xojo 2019 Release 3.1 hit the internet.  This small bug fix release is a critical update and is recommended if you are using one of several areas.  Let’s get into the details.

One of my biggest issues of concern with API 2.0 is with a dangerous memory leak in the DatabaseRow class.  Doing practically anything with a database would quickly eat of RAM until it brought your machine to its knees.  R3.1 fixes this issue and also a memory leak when using ODBC.

A couple of iOS bug were fixed in this release.  R3.1 fixes a regression that caused iOSTextAreas to overflow their bounds when the border was set to None or Regular.  iOSView headers no longer show the previous view during the PushTo animation.  Xojo added the Operator_Compare to the ColorGroup so that it can be compared against a color value.

A number of API 2.0 bugs (besides the database bugs noted above were fixed):

  • TextArea.SelectionAlignment now accepts enum values.
  • String.IndexOf now properly matches its signature when you leave off the startPosition but include ComparisonOptions or Locale.
  • If an empty name is used in the TimeZone constructor it will create an instance for the current timezone.
  • String.LastField now works
  • SerialConnection.Connect no longer raises an Error event.  It now throws an exception as expected.
  • DateTime no longer reports a Nil TimeZone

In Windows, having multiple HTMLViewers on a window (or multiple windows) no longer continuously switches focus.

In MacOS setting FolderItem.Visible no longer inverts the visibility.

The Plugin SDK now lets you access the new API 2.0 string extension methods.

The burning question that everyone wants to know:  Do I think that Release 3.1 is safe to use?  The answer is a definite maybe.  Let me explain.

I’m still not sold on API 2.0 being completely stable.  A few additional bug reports were filed after R3.1 was released including a GenerateJSON bug with Variant arrays (Feedback 58940), and a DatabaseColumn.Value bug where value always returns a String value (Feedback 58934) where it should be bringing back the correct data type.  Both of these bugs are marked as fixed and ready for 2020 R1.  Unfortunately we don’t know when R1 will drop but if I was a betting person I’d guess sometime in March either the week of Xojo.Connect or maybe even later.

If you’re using Classic API then I believe R3.1 is safe(ish).  I’ve experienced some oddities in the Constants Editor but I can’t replicate an issue where it reverts the value with no intervention on my part.  The new ColorGroup Editor for iOS projects just seems sluggish but that may just be the result of the new ColorPicker.  If you’re doing iOS projects you pretty much have to use R3.1 to stay up to date.

I have migrated a few projects to R3.1.  A few that I’ve attempted have had compilation issues and I haven’t gone back to determine if they were plugin or code issues and frankly I’m not that big of a hurry to upgrade.  R1.1 is still working fine for me and I don’t need the hassles involved with major Xojo upgrades.

So my advice is to test the heck out of your projects if you upgrade to R3.1.  I say this every release (because its true) but if you’re using API 2.0 then massive testing is a necessity. I put it this way: do you want to bet your company and/or product on trusting a new API?

What is your experience with 2019 R3.1?  Is it worthy?  Are you holding back and, if so, why?

12 thoughts on “Xojo 2019 Release 3.1

  1. Haven’t jumped on R2 or R3 yet as client projects dont demand it
    One day they may – but not yet
    I’ve poked and prodded it and found my own share of bugs and reported them
    Nothing critical to my projects or that a fix would suggest I MUST update to r3.1

    So at this point 2019r3.1 and newer versions are “wait and see”

    • Not too many – had guests over for the game so couldn’t get too wild and crazy. Was up really late though so this morning was a little rough.

      Go Chiefs!

  2. GOLANG talk https://youtu.be/sX8r6zATHGU touches on many frustration points in any computer language and api dependency. Can Xojo compete with these guys? GOLANG only costs your time. GUI framework is Qt. It does not support inheritance for good reason.

  3. Qt has issues as far as commercial deployment goes – its not free nor is it inexpensive. Its cost per seat can be prohibitive for smaller development shops.

    However, using Xojo for front end UI and go, rust, swift, etc as the underlying language for helpers and dll’s might make a pile of sense
    I know some places that are doing exactly this

    • I’m no expert but I’m not sure if that is true. Their LGPL licence allows you to develop and distribute your closed source application at no licence cost so longer as you use dynamic looking to QT libraries

      • You forgot an important part: … and as long as you don‘t charge for it.

        If you are happy to give your software away and just charge for support then you are in the clear.

        If you want people to pay you then you need the commercial license.

        Just because many developers happily produce commercial apps without a commercial license doesn‘t mean it is ok.

        Many MySQL users fell into that trap, got sued, and had to pay a LOT of money. That‘s how MariaDB came to be (a clone of MySQL).

        • Hi Markus, I’ve looked and I can’t see where it says you cannot charge for your software if you link dynamically as per the terms of the LGPL licence and keep your own code private. I’m pretty sure that’s not the case though the QT Licensing is difficult to understand.

    • That‘s the best bit – they don‘t even have to explicitly write it. It is implied in the license structure:

      Starting from Qt 5.7, Qt is licensed under
      • Commercial license
      • LGPL3 open source license
      • GPL2 or GPLv3 open source license

      Is your software open source? Or is it commercial? If it is commercial then you need a commercial license.

      From https://www.qt.io/licensing/:

      „Qt for Application Development is dual-licensed under commercial and open source licenses. The commercial Qt license gives you the full rights to create and distribute software on your own terms without any open source license obligations. With the commercial license you also have access to the official Qt Support and close strategic relationship with The Qt Company to make sure your development goals are met.

      Qt for Application Development is also available under GPL and LGPLv3 open source licenses. Qt tools and some libraries are only available under GPL. See the comparison chart for details. The Qt open source licensing is ideal for use cases such as open source projects with open source distribution, student/academic purposes, hobby projects, internal research projects without external distribution, or other projects where all (L)GPL obligations can be met.“

      The problem with commercial software is that it is near impossible to meet all requirements of LGPL3. It‘s much more than just dynamically linking some libraries.


      „The general Qt toolkit, consisting of Qt Essential code libraries, the Qt add-on APIs, and the Qt Creator IDE are available dual-licensed for commercial and GPL licenses. Most of the Qt APIs are available also under LGPLv3 license but not all of the Qt Add-on modules.“

      Now which developer uses only the „open source components“ of Qt?

      Furthermore most commercial licenses forbid reverse engineering – a contradiction of the LGPL3.

      And you CAN‘T fulfill the LGPL3 conditions for iOS or Android development (eg it requires the user to be able to replace the dynamically linked libraries), so you need a commercial license there.

      But hey, I‘m no lawyer. But nobody could show me where Qt actually states that you can sell commercial software created with the free version. On the contrary, they go out of their way to NOT say it.

      Have a look at this old FAQ from the free version 3.3: it is bizarre which questions they answer while the most important one does NOT get answered.


      While in the old FAQs for the commercial version


      it clearly states: „You may only write commercial, proprietary and non-free software if you have purchased the Professional Edition or the Enterprise Edition.“

      Nowadays it has been a lot more obfuscated, but I would be willing to bet that most commercial developers using the „free“ Qt are actually breaking their license agreement.

      P.S. all the guys claiming on SO that „of course you can“ sound just like the guys who said of MySQL „of course you can“.

      • I don’t think there is any similarity with the MySQL situation. Anyone spending a small bit of time looking at its licensing would have understood its implications for closed source software.
        QT on the other hand offers an LGPL option. Ás long are you take care to not use those parts of QT not covered by this AND you fulfill your obligations under LGPL terms (dynamic looking to QT libraries primarily) then you are covered.

        • Again: where does it say that? Because Qt goes out of their way to not say that. And THAT, the refusal to answer a simple question, is where alarm signals should go off.

          • Will I suppose the short answer is that if you offer under the LGPL licence you are beholden to it’s terms. I agree with you though that they could try to make it more clear. Perhaps they are happy for people to be uncertain so that more will buy commercial licences.

Comments are closed.