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?

Why Do People Leave Xojo?

I’ve been a member of the Xojo community for nearly twenty years.  In that time I’ve seen a lot of people join the community, become fantastic contributors, and then suddenly leave the community.  There are a lot of reasons developers would leave the community but I thought I’d capture some of them.

Xojo scratches an itch and if the developer no longer has the need to scratch that itch they use a tool that scratches their next itch.  Xojo is great for cross-platform applications but certainly less so if you need only a Mac or only a Windows application.  Xojo’s strength is cross-platform which means compromises in abilities and controls so I can understand people wanting a pure Windows or MacOS application.  Apple and Microsoft have large developer communities that are attractive.

The Rapid Release Program held much promise when it was introduced many years ago.  Xojo went from two big monolithic releases a year to three, four or more releases per year.  Sure, Xojo fixes a ton of stuff in each release but they also seem to break stuff in each release.  I know we have a list of verboten releases for various platforms and it gives the impression of a perpetual beta status for Xojo.  I have been a big fan of releases that are almost all bug fixes with no new features but those are pretty rare.

Xojo is a modern object oriented language and is quite powerful but it’s not a popular language.  Many developers have never heard of Xojo.  There is no standards committee that adds features to the language and the language itself is closed source.  If there was a standards committee I suspect there would be some serious language additions done sooner rather than later.  It certainly would have given much more forethought into API 2.0 and how it would affect the existing user base and the documentation done long before any coding started.

Xojo isn’t like any other development tool I’ve ever used.  It’s great that it doesn’t allow a developer to make a stupid mistake when declaring a method.  It forces you to use the Xojo IDE user interface to do everything from creating methods, declaring properties, constants, enums, etc.  I’ve never used another developer tool that does this.  Xojo pretty much forces you to use it the way they want you to rather than what most other languages do with a text editor.  This makes it easier for beginners but if I’m being honest it’s a drag for someone like me that (usually) knows what they are doing.  Forcing developers into the Xojo-way of doing things makes the IDE seem like a toy at times.  It’s certainly slower.

Change does not happen quickly with Xojo.  It has a small development staff and I’m always amazed at how much they get done.  But it means that it can take an incredibly long time for things to change and become stable.  The transition to 64-bit was a huge multi-year project.  iOS was a huge multi-year project.  Web 2.0 and Android have become huge multi-year projects (with still no idea on when we’ll see them).  The new targets might be good eventually but history shows it will take a few releases before they’re really stable.  Meanwhile older targets seem to get significantly less attention.

Xojo isn’t really a business development tool.  When I say business I mean databases and reports because that’s practically every application we’ve done for the past twenty years.  Doing database development in Xojo is NOT Rapid Application Development (RAD) because you have to deal with everything database related yourself and the IDE and compiler give you zero help.  Reports are simplistic and aren’t exceptionally powerful and there’s no way for an end user to create or edit reports.  There’s a reason why BKeeney Software has its own database Object Relation Model (ORM) classes and reporting tools and classes because we have to use them in nearly every project we do for clients.

In addition to all that it’s really missing some things that business users need.  The TextArea control has pitiful RTF support, there is no built-in calendar, date, or time controls.  The built-in grid (Listbox) is more powerful than many people give it credit for but cannot hold native controls and can be very slow with large data sets.  There is no PDF read or write support either.  There are 3rd party options for all of these things but something lightweight would go a long way to supporting new business users.

These are a few of my thoughts.  What am I missing about developers that leave Xojo?  And is there a way to stop them from moving away from Xojo?  What are they doing to?

Xojo MVP’s

Xojo announced today the creation of the Most Valuable Professionals (MVPs) advisory board. More information here: https://www.xojo.com/mvp/

Having ‘known’ these five Xojo developers for many years (mostly online and a few in person) I think they are an excellent group to advise Xojo. Most of these developers have many years of Xojo experience ranging from being 3rd party control and library developers to consultants to commercial application developers.

It makes me happy that every single one of the developers on the Advisory Board is what I would call part of the ‘professional’ developers of Xojo. It is surprising, however, that there are no ‘citizen’ developers on the board. So I call this a mixed signal to who Xojo is trying to appeal to (obviously it’s everybody but I think you get my point).

The Association of REALbasic Professionals (ARBP) tried to do this ten years ago with no success. The groups mission was to help inform Xojo (then Real Software) on what the professionals wanted out of the tool. If I recall correctly the only thing that was ever implemented out of our top 5 list was reporting. Grids, PDF support, and more basic controls never materialized. Sadly, we all still want those options.

It’s not being said but I believe the MVPs Advisory Board is a direct response to the virulently negative (and vocal) reaction by some Xojo developers had with the rollout of API 2.0. I am one of those developers and it is no big surprise that I was not invited to be on this board and, if I’m being honest, I’m not sure I would have accepted anyway.

We don’t know how the advisory board works, or even if it will significantly change how Xojo approaches future changes. Even if they do have significant input I’m not sure we’d know unless Xojo specifically tells us.

Good luck to this group and Xojo: There are some relationships to mend.

What are your thoughts about the MVP’s?

Databases and Xojo API 2.0 And Why I’m not Using it Yet

Now that API 2.0 is more or less been through two releases (2019 R2.1 and 2019 R3) many Xojo developers are starting to poke around with API 2.0 in their database applications.  There are many things to like about the changes to the database classes and our own ActiveRecord class does many of these things.  Things like throwing exceptions when there are errors definitely get your attention whereas in API 1.0 unless you check for the error you may not know anything bad happened.  The built-in Prepared Statements are a super nice change too.

Despite all the good things with the db classes in API 2.0 I recommend holding off until one, very important bug, is fixed.  Feedback case 58739 is such a huge risk that you simply cannot use the new API 2.0 classes in your Xojo projects yet.

The essential detail of that case is that Xojo is not releasing objects as it should.  Norman did a test case and showed that when using API 1.0 his test project had 24 objects at the end of the test run.  Doing the same thing in API 2.0 had over 43 million still unreleased objects!  This means there is a huge use of memory in the application and in 32-bit applications it will simply crash once it consumes 4 GB of RAM.  64-bit applications will last longer but still bring your computer to its proverbial knees.  

The Feedback case talks about SQLite and in-memory databases but other reports are that it’s in other databases as well including ODBC and MS SQL Server (case 57978).  The good news is that 58739 is marked as fixed as of January 7th, 2020 (57978 has not been updated).  But unless Xojo issues a point release to 2019 R3 we won’t see this fix until 2020 R1 is released and there is zero evidence of that happening any time soon.

Several people have contacted us about an updated ARGen that generates API 2.0 code.  We are holding off until we feel API 2.0 is rock solid.  So until this is fixed we are not using or advocating for API 2.0.

Have you found anything else in API 2.0 that should discourage Xojo developers from using it?

Xojo: VB For the Mac

Last week we asked the question “How Did You Find Xojo?”  A vast majority (60%) of the responses said web search of some kind was how they found out about Xojo (or REALbasic or Real Studio).  Some found Xojo via software discovery CD’s that were bundled with Mac specific magazines over a decade ago (that seems wrong to write it like that).

More than a few users had comments that they had been using Visual Basic (VB) and wanted something like it for the Mac.  Some even said that they searched for “VB for the Mac” and Xojo was one of the results.

I get it.  I spent quite a few years working on a big accounting application written in VB6.  It was big enough where we had to refactor the project because we couldn’t add any more modules or class objects to it.  It used many third party controls that helped in development (think text field formatting, fancy grids that could hold any other control, and multiple reporting tools).  

The project was only ever going to be on Windows so there was zero thought about a Mac version.  But that didn’t stop me from thinking about it.  Every now and then I’d try to do something in Xojo to prove that I could do it.  With the exception of the fancy grid there were few things I couldn’t get working in Xojo.

Even though VB6 and Xojo are BASIC languages there isn’t much similarity between them.  VB6 compiled applications that required the VB6 runtime while Xojo applications are compiled into self-contained packages.  On the Mac everything required by the application is in the bundle whereas on Windows and Linux libraries needed by the app are put into a folder right next to the executable.  Xojo Windows apps don’t need to use an installer but since Windows users expect an installer it’s easy enough to use.

VB6 is over fifteen years old.  It didn’t have much in the way of modern language features such as object inheritance.  You spent a lot of time and effort manipulating controls to do what we’d consider ‘normal’ things (I seem to remember ListBoxes being this way).  In Xojo you can extend and subclass practically everything.  Is Xojo a perfect language?  Oh heck no, but it’s light years ahead of the fifteen year old VB6 and it’s still evolving and improving.

Xojo doesn’t make perfect Windows, Mac, or Linux applications.  It’s often a compromise for something that works ‘well enough’ on Mac, Windows, and Linux applications.  So the fancy grid’s that you could purchase for VB6 don’t really exist for Mac and Linux and Xojo reflects that.  But you can certainly design a really good application that doesn’t need the fancy grids.  MacOS users tend to like ‘elegant’ solutions and, to be honest, the fancy grids aren’t an elegant solution but they certainly work (especially for accounting applications).

The third party community for Xojo isn’t nearly as big as the VB6 world.  Generally there are fewer options but the options are considerably less expensive.  We’d spend a couple of grand each year per developer on licensing for third party tools.  As a Xojo consultant we spend about that much for the entire staff each year.

We don’t get many requests for VB6 to Xojo conversions any more.  We used to get ten to twelve a year but it has definitely slowed down the past couple of years.  I suspect that any remaining VB6 applications are in maintenance mode and their owners don’t want to invest in a rewrite.  If they did, they would have already moved to a new development environment.

VB6 applications still work in Windows 10 and if memory serves Microsoft has said they’ll support the VB6 runtime for another ten years.  This means that there must be a LOT of VB6 applications still around.  Support for the VB6 IDE has disappeared and the last time I tried I couldn’t get it to install properly in Windows 10 so I just went back to my Windows 7 VM.  But now that Windows 7 support has expired it seems that those old VB6 applications might be on life support.

Many of us came in to the community looking for VB for the Mac.  We’ve been using it for nearly 20 years and have a stable of clients that are happy with a single code base for their commercial Mac and Windows (and occasionally Linux) applications.  I’d say Xojo has been more than good enough.