Xojo 2019 R1

Xojo 2019 R1 was released today. This is the 2nd release in a row where there is not a dramatic number of new features but quite a few bug fixes and enhancements. Let’s dig into what’s changed in this release!

The big change in this release revolve around the URLConnection control. The HTTPStatusCode property is now available for both the Send and SendSync calls. The control now appears in the library. It now yields to other threads. Send requests are now closed before the ContentReceived and FileReceived events are fired. The string encoding for the ResponseHeaders is now consistent across platforms. It also now automatically handles compressed content-encodings in Windows and Linux (just like MacOS does). The TimeOut property now works (before it always did 30 seconds). Error messages are no longer empty in Windows. The ReceivingProgressed event now correctly reports the total bytes. The response headers are now updated property when a request is made. The SendSync no longer intermittently returns empty strings in MacOS.

The licensing has changed for Raspberry Pi. The license for Desktop and Console applications on the Pi is now free!

There are some other new items. The list is small but significant. The first is that 32-bit Windows builds can now set HiDPI and supported versions properties in the manifest file.

The TextArea control for Windows 8 (or newer), and Linux now support system spell checking. This matches the behavior on MacOS.

The Text datatype now has target appropriate EndOfLine properties. If you use Text you’ll no longer have to create your own EndOfLine constants.

The IDE added the ability to switch between Computed Properties and manual Getter/Setter methods. There is a new menu item when right-clicking on a property. In addition to the standard Convert To Computed Property there is a new menu item called Convert To Method Pair which creates two overloaded methods. For example, if you have MyProperty as Integer and select the Convert to Method it will create one MyProperty method that returns the integer value and another overloaded method that accepts an integer value with an assigns. So it looks like to consumers of this property as if nothing changed.

The constants setting has been changed from Dynamic to “Localized.” This creates a new grouping in the Code Editor called “Localized Strings”. It’s still a constant but it better reflects that it’s localized and should make it easier to visually see if a string is localized or not as there was no easy way to tell before.

There are 25 changes and 162 bug fixes for Xojo 2019 R1. Here are what I feel are the significant items:

The ODBC Database plugin now works better with 64-bit builds. Date fields in MacOS now work properly. In 64-bit Windows updating a binary/image column no longer fails with an invalid precision error.

The MySQLCommunityServer plugin no longer crashes when has certain field types and originated from a PreparedStatement.

The SQLiteDatabase no longer crashes when out of memory situations arise – an error is now generated.

Calling an OpenDialog from within a thread now properly raises a ThreadAccessingUI exception. I’m actually surprised that this wasn’t flag a long time ago.

StringShape rotation is no longer incorrectly offset. The original Feedback report was for Linux but it appears this affected other targets too.

The Window/Canvas Backdrop picture now draws correctly in HiDPI. This doesn’t affect me directly but this is the first time in several years where Canvas drawing in Windows seems really solid. I’m in testing right now with a client app that had been held back in 2017 R2.1 because of Windows drawing performance.

GroupBox caption in Windows now properly draws the size, bold, italic, and underlines styles instead of ignoring them.

A bunch of work was done in the Code, Constant, Layout, and FileTypes editors. The Inspector and Library received a little love too.

You can read the release notes at http://docs.xojo.com/Resources:2019r1_Release_Notes to get the entire list and see if anything affects you.


So far I’ve found this release to be solid and the major updates to URLConnection now appear to make it worthy of investigation. I’ve not used it enough, yet, to recommend it but I think most of the major bugs are worked out. The number of bug fixes and enhancements makes R1 a worthwhile upgrade.

I think this version is worthy of your time and effort to try out. As always, you should really test Xojo out on your projects, in all targets, to make sure it works as expected. Some of the bug fixes in this release might mean you have to get rid of some workarounds you’ve come up with (thinking of the StringShape rotation fix here).

You can download the new version at https://www.xojo.com/download/

Let’s hope that the major new features (like API 2.0, Web 2.0, and Android) can be staggered so there there isn’t a flood of new things in a single release. Too many new things makes it hard on beta testers.

Have you found any showstoppers? What are you most happy about in this release?

Until next time, Happy coding!

11 thoughts on “Xojo 2019 R1

    • I only can echo Geoff’s comment. I have a few projects with an unhealthy amount of controls. Whenever the client wanted controls to be moved around or even new fields I became nervous. With the new release all those sorrows and concerns are gone. It’s again fun making UI changes on big projects. Thank you xojo team.

  1. And quite some bugfixes not worthy of being used for marketing that make built applications more reliable. To pick out two: Lowercase now works correct with WindowsANSI String. Getting the length (using Len) of a string (which may have an unknown encoding) now returns a consistent length across platforms. You might guess the subtle issues/bugs that could have caused in your applications since you wouldn’t expect that (and in many cases only occurs depending on the user’s data that’s being processed).
    While Speed using the IDE’s Layout Editor has improved, the Code Editor is now behaving unexpected (and breaking my workflow) when navigating through code in Tabs (FB 55410). Not a showstopper, but really annoying. In my usage, I probably loose more time than I gain with the improved Layout Editor 🙂
    At least 2019r1 seems to be solid for the built applications – they benefit a lot from all the framework related bugfixes.

  2. Super excited about these fixes: “The ODBC Database plugin now works better with 64-bit builds. Date fields in MacOS now work properly. In 64-bit Windows updating a binary/image column no longer fails with an invalid precision error.”

    These previous issues prevented me from publishing a 64-bit version for Mac and Windows. Now, I’ll have a bunch of very happy customers that want / need to run 64-bit!

    Thank you Xojo (& William in particular!)

  3. Oh my. Thanks for this blog Bob. I read it via RSS and so you Don’t see my read hit. But I really enjoy your take.

  4. “I’m just tickled that people read the blog”. At EVERY single release, it’s the second place to be read just after the release notes. And then checking the Xojo forum for few days looking for stability.

    • Aww…thanks. I try to do basic testing with Xojo before every release. It’s a lot of work, so I try to hit the highlights of major changes, and I check the beta list comments to see what they’re having issues with.

      I must admit that I like these smaller new features releases that are heavy with bug fixes.

      • “I must admit that I like these smaller new features releases that are heavy with bug fixes.”

        Which of course used to be standard before the introduction of the Rapid Release Model. That model plays on developer’s greed (“Want new features [even if buggy]”) to the detriment of stability and reliability (“perpetual beta state”).

        • I disagree, Markus. Before the Rapid Release Model you had the big monolithic releases once or twice a year. I found them to be incredibly buggy and almost all of them required a dot release or two to fix all the bugs. The Rapid Release Model also fixed more bugs in a more timely manner than the old release model.

          I think the RRM also helps us beta testers. Fewer new things to test. More bug fixes to test. In other words, a more incremental approach to software development.

          I get it, you’re not a fan of RRM. But I don’t think it’s any worse than the old model and much better in some ways.

          • If your main point is making life easier for beta testers then yes, you have a point. If your goal is a stable development platform then you do not.

            You had yearly releases that were followed by 4 or five bug fix releases. The end result was a pretty usable release without major bugs.

            Compare that with the perpetual beta quality you’ll get now where EVERY release seems to have a showstopper bug.

            If you are not affected by major bugs then good for you. Others are not so lucky. For us we can’t use certain versions for certain projects because of major bugs. My last license renewal was a complete waste of money, and I know that others too had to go back to 2017r3 to avoid major bugs in the newer releases.

            So no, I don’t like the Rapid Release Model.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.