Xojo 2020 Release 1

Xojo 2020 R1 was released today.  The last major release of Xojo came nearly 9 months ago.  This much anticipated release has a completely rewritten from the ground up Web API that takes Xojo web applications to a whole new level in terms of look and feel with themes, new controls, and new functionality.  This release also brings a ton of new and improved functionality to desktop applications too.  Let’s dive into it!

Web 2.0

The elephant in the room in this release is Web 2.0.  Web 2.0 is a complete reimagining of what Xojo web applications look like.  

Controls galore.  Web 2.0 comes with all of the web 1.0 control (see exception below) and a host of new controls that look and feel really nice.  Among the new controls:  Audio Player, Breadcrumb, Chart, Date Picker, Pagination, Search Field, and a host of specific TextField types like email, number, password, and telephone.

Every standard control (buttons, text fields, etc) have a wide variety of new options that I think will make developers happy.  The new WebListbox has monster changes and I really can’t do it justice in this review.  Among some of the big additions is the ability to load data dynamically using the WebDataSource.  If you’ve used iOS in Xojo it acts pretty much the same way and allows you to have practically unlimited numbers of rows of data and it will load the data as the user scrolls.  This means you don’t have to page your data (though you can if you want by loading the data manually in combination with the new Pagination control).

Even more interesting are the new WebListbox Cell Renderer classes.  In this release there are four built-in with DateTimeRenderer, ImageRenderer, StyleRenderer, and TextRenderer (the default renderer that doesn’t need any special action on your part).  The DateTimeRenderer lets you specify the Date and Time format styles but also a Relative Style (like “Today” and “Yesterday” values with time) and it also localizes the data to the users locale.  The ImageRenderer is pretty straightforward to view images, the Style lets you set the style of an individual listbox cell and, of course, the TextRenderer is the default.  The WebSDK example comes with a Button Cell and Color Cell renderer too so it should be exciting to see what developers do with for this.

While Web 1.0 had WebStyles they really were hard to use. Web 2.0 uses Bootstrap and that gives you an incredible amount of variety available in your Xojo web applications.  While there’s a default bootstrap theme there is no theme editor in this initial release but it’s not so hard to change the theme on your own.  One way to change the theme is to go to https://pikock.github.io/bootstrap-magic/, save the css file to your computer, rename the file to boostrap.min.css and add to your project.  Users can download pre-made bootstrap 4 themes from bootswatch.com.  Unfortunately the IDE doesn’t render these themes very well but it works at runtime.

Web 2.0 projects compile only to standalone now so you no longer have the option of using a cgi version.  Xojo Cloud users automatically get load balancers for your applications and you get the same number of application instances as you number of cores on your server plan.

While most of Web 2.0 is very exciting and enticing those that have an existing Web 1.0 project will most likely not be very happy.  The conversion process is a one way process and not everything converts.  WebAnimator does not have a Web 2 counterpart and WebStyles are completely reimagined so while the compiler won’t complain if your code uses an old WebStyle it’s pretty much ignored.  I would even say that the conversion to Web 2 is broken to the point where it would be easier to rewrite your project into Web 2 than it is to try and convert it.  Default control heights in Web 2.0 (38 pixels tall but depends on the theme) are considerably bigger than Web 1 (22 pixels) so I find it hard to imagine that most layouts wouldn’t need considerable work to get correct for Web 2.0.  It sucks, but that’s the reality of it.

There are some missing parts in the IDE that are disappointing as well.  The WebToolbar and WebStyle editors are missing in Web 2.0 but the good thing is that both can be created in code.  Web 2.0 does not have control sets implemented at this point.

It’s also disappointing that not all of the Web 2.0 examples are working properly or are so simple as to be useless in learning how to use Web 2.0 (I’m looking at the WebListBox examples).  The documentation for Web 2.0 isn’t as clear cut as I’d like too and I disagree with some of the property groupings for the Inspector.  For example in a WebLabel and WebLink there are Font properties to set the font properties but a WebTextArea does not have this and you have to manually set them via the Style property.  Why does one control have it exposed and another one does not?  Xojo has one shot to impress developers with this release and inconsistency is a bad look in my opinion.

Everything Non-Web 2.0

While Web 2.0 is by far the biggest part of 2020 Release 1 but it is not the only important change.  Here are some of the highlights.

Desktop Changes

Listbox Header drawing events.  New in R1 is ListBox.HeaderBackgroundPaint and HeaderContentPaint.  This allows the developer to have total control over the drawing of the headers.  Want to draw an image, or change the background color, or even change the sort indicators?  No problem now with these two events.

TextArea now has a UnicodeMode that allows you to change the way the control treats characters.  The default is Native and that doesn’t change anything.  The Characters setting counts by the single character regardless of the byes used and the Codepoints setting counts by number of Unicode Codepoints (bytes) it requires.  The Codepoints way is what you’d have to use for an emoji.  This is a nice addition from the the old Xojo Framework.  They also now have a String.Characters iterator.

For years Xojo developers have had to rely on third party plugins to create PDF documents in Xojo applications.  New in 2020 R1 is the PDFDocument class that allows you to create a PDF document fairly easily using simple graphics object commands.  PDFDocument does not support transparency so you’ll have to consider the order that you’re drawing items and you might find it hard to create some forms of documents.  All in all this is a great addition to the product that many people will like.  PDFDocument is available in all targets excepts iOS. It’s not perfect but for many users it will be good enough and hopefully they’ll add some features to it in future releases.

Linux applications now have a Normalize Control Sizes build option.  It normalizes the controls widths/heights, removing theme specific padding and adjustments to make controls on any Linux distribution look similar.

XojoScript’s can now be saved in their compiled form into a MemoryBlock and that means you can read and write them to a file.  This should allow XojoScripts to be considerably faster since they may not have to be recompiled every time they’re used.  If you use XojoScript I think you will really like this feature.

HTMLViewer has a new event called JavaScript request that gets raised when using the ExecuteJavaScript and ExecuteJavaScriptSync methods.  This should eliminate the need to use third-party code to do the same thing.

Project loading and compiling of desktop applications is considerably improved.  In my testing it’s about the same speed as Xojo 2019 R1.1. Gone is the slow down users experienced after they did a check project.

There are dozens of other bug fixes and changes that I could tell you about but I’ll leave the joy of reading the release notes to you.  Why should I have all that fun?

Overall Impression

Xojo 2020 R1 is a huge release that’s been in the making for long time (if we’re being honest the wait was too long).  Web 2.0 has a lot of exciting new features, controls, theming options that should excite developers.  Converting projects is very hard and I think learning the new controls is harder than it needs to be with incomplete documentation and examples that are either not working or weak.  I really don’t have a real good feel for how stable Web 2 is simply because I’m not working on any web projects currently.  I suspect that there are bugs to be found as more people start stress testing it.  But it’s a good start and I look forward to the missing pieces being filled in as time goes on.

Obviously Web 2.0 is the big star of this release but the PDFDocument class is a great addition that users have been asking for years.  The other bug fixes and changes are also big and even if you aren’t a Xojo web developer this is a big and important release. I’ve been using R1 for desktop apps (Mac and Windows only) and I’ve found it to be stable and I have no complaints (other than no being able to turn off API 2 items).

What say you Xojo developers?  Is Web 2.0 worth the wait?  Is is stable?  What do you think it’s lacking?  What do you think about the desktop changes?

A New Version of ARGen

Tim Parnell of Strawberry Software has released a new version of ARGen with some exciting changes. New to the ActiveRecord utility is a Microsoft SQL Server database adapter class utilizing the SQLDatabaseMBS plugin (you’ll need an MBS license for this). Now your Xojo Mac application can use a SQL Server database.

ARGen is a great utility that generates Xojo code, classes, and user interface elements (think basic list and add/edit windows) that ties interfaces to your database. ARGen can save you many hours of tedious coding by abstracting the database code to read, write, and interface with controls.

Another new feature is called Quick Resolve that will automatically deselect incompatible tables. ARGen will show you an error view if you have tables that do not have primary keys (ActiveRecord requires tables with a primary key), or other errors, and allows you to remove them from the list. This should be a big time saver for some Xojo developers.

Postgres database server users can now use SSL connections.

The namespace template has been updated to provide thread connection pooling for Desktop targets.

For large databases ARGen is now faster in the project generation with improvements to the internal XML creation.

Many more improvements, tweaks, and bug fixes are in this release.

The 2020.02 release is free for existing 2020 users and is highly recommended for all users. Be sure to check out the product page as there have been a number of changes since I last posted about ARGen.

For more information and to download please visit https://strawberrysw.com/argen.

The newest version of ARGen

ARGen is no longer a BKS product but I’m still a user and I’m very excited about the things that Tim from Strawberry Software has done with it in the new release. Besides an obvious facelift there are some very nice features that have been added.

API 2.0 is now supported along with classic API. This should come as no surprise since Xojo moved to API 2 that ARGen would eventually support it and was a highly requested feature. If you select API 2 all code will switch over to the appropriate syntax for you including all of the hidden Xojo database classes that ActiveRecord uses. If the project type doesn’t support API 2 (like Web and iOS projects) it’s not an option.

Multiple database connections/classes supported in one project. Way back when we originally created ARGen and ActiveRecord we never envisioned that we’d ever want more than one database in a project. Thinking back that was a silly assumption but in ARGen 4 you can now have multiple databases, or namespaces, and each one does its own ActiveRecord thing.

Console project type added. Again this is a silly oversight on our part long ago but since since we didn’t do many console projects it makes sense that we didn’t have it. This should make adding helper apps much easier.

A new Verify class function detects deleted fields. ActiveRecord has always been able to detect newly added fields when running in the debugger that warned the developer if the Xojo class was missing a property for a database column. The new Verify class does the opposite: does your class contain a property that at one point we thought was a database column but no longer exists in that table? Before this version that was a silent failure as it didn’t detect it so at least now you can take care of it right away. When working on a big project with multiple developers touching the database this will be a huge help.

Foreign keys that are nil are inserted as NULL values. This was always a huge user request that ARGen handles gracefully. Whereas before it inserted zero’s or blanks (depending on primary key field type) it will now put NULL’s where appropriate. This allows better relational integrity and plays better with relational databases.

The User Interface generation has been cleaned up. No longer do you have the choice of a regular window and/or container for lists and add/edit UI – everything is a container control and this simplifies some choices that I think most users will really like.

Remember that ARGen is all about getting your Xojo database project going as quickly as possible that the tedious coding part is done for you. This version of ARGen takes that to the next level with many of these features. Obviously Tim will tackle Web 2.0, iOS API 2 and Android whenever Xojo releases them to the public. The future of ARGen is bright!

There are little changes throughout the product and the resulting project that I think you’ll be happy to see. A new ARGen license costs $99. Existing ARGen (from BKS) users receive a 20% discount when upgrading. All existing users should have received an email but in case you haven’t please send an email to workshop@timi.me.

For more information on ARGen 4 please visit https://strawberrysw.com/argen/.

Whither Xojo 2020 Release 1

The Xojo drought we’re experiencing in 2020 is starting to become ridiculous.  The last release, Xojo 2019 R 3.1, was released January 23rd, 2020.  As of today we’re at 152 days.  

The longest previous delay between releases was 143 days between Xojo 2012 R2.1 (January 12, 2013) and 2013 R1 (June 4, 2013).  If I recall correctly this was the transition from Real Studio to Xojo and was when the IDE went through a massive redesign (and ironically I was accused of causing a 6 month delay due to a blog post).

Come on Xojo.  There are plenty of bugs and enhancements that should be shipped NOW.  Is the Rapid Release Model being replaced with once a year monolithic releases?

Write Code That Your Future Self (and Others) Won’t Hate

One goal we should all strive for is to write code that is clean and simple enough that when we look at it six months or six years from now there’s no issue figuring out what it does. Or, as I like to put it, write your code so that your future self doesn’t invent a time machine to keep you from doing something stupid.

This week Javier from Xojo wrote a blog post at https://blog.xojo.com/2020/06/03/using-class-extensions-to-validate-email-and-url-data/ that shows the simple string extensions IsEmail and IsURL. On their face these are nice examples of using Extension to do something useful in Xojo.

Everything is fine until he says this:

“With using the “ByRef” keyword we are instructing Xojo to give us access to the original data; and in that case we will be able to modify the received data through the given variable name in the Parameters field.”

Again, on its face it’s no big deal but this is exactly what my future self would have a conniption fit about. Why? Because when I see IsEmail and I get a boolean back I will assume (as would most developers) that it’s a simple check to see to see if the string is a valid (or valid enough) email. What I absolutely would not expect is for my source string to get modified.

You see, “IsSomething” means true or false in my book. Not, I’m going to mess with your original data. So when your future self sees that there’s an IsEMail method are you going to go look to see the implementation details? Of course not because IsWhatever that returns a boolean seems pretty straightforward and your boss needed the code yesterday.

If you’re going to create a method that massages the data I wouldn’t use an “Is” prefix. Perhaps an extension method that does this should be named “TestAndReturnEMail” because then you’ll at least look at it and go what the hell was I thinking. But then again, using Extends is probably not idea for testing and modifying a string you think is an email. There’s probably a half dozen ways of doing this better.

My general rule of thumb: if you have to look at the guts of a method to determine what it does you’ve already lost. You really think you’re going to remember that IsEmail six years from now mucks about with your original string? I know I won’t.

In my opinion this is the exact wrong place to use ByRef. Feel free to disagree but if I had one of my developers do this I’d be very disappointed.

Xojo Design Mistakes Video

Xojo released my 2019 Xojo Developer Conference video on Xojo Design Mistakes on YouTube a few weeks ago at https://www.youtube.com/watch?v=s-FOUxAtK7I&feature=youtu.be.

I liked my alternate title better: Thankfully time travel hasn’t been invented otherwise my future self might come back to murder me because of stupid decisions.

Based on feedback many people found the video to be useful. Hopefully you do too.

The reason I brought this up today is that I’ve spent the last week working on optimizing several large Xojo projects. I’ve identified several areas to look at and if I think it’s it might be worthwhile to look at (after using Instruments and Profiling) I will create a small sample project proving if I can make it more efficient. There are several things that I believed to be true that are not. Here is my initial list:

NthField is Slow: It’s not fast and I wouldn’t recommend using it in a huge loop but it’s not *that* bad. Converting a project that uses it a lot to use Split and then bounds checking just isn’t worth the overhead and hassle of screwing up the code. Plus, it’s one-based whereas Split creates a zero-based array.

String Concatenation is Slow: Again, it’s not exactly speedy in loops but we’re talking ticks if the strings are relatively short. If you use something like this:

dim someString as string = "First line " + _
" second line" + _
" third line"


it is way faster than:
dim someString as string = "First line "
someString = someString + " second line"
someString = someString + " third line"

MBS Functions are always faster: Sometimes MBS *is* faster but not always. Things like picture saving is actually pretty efficient in Xojo. Directory scanning *is* faster using MBS but only in classic API. If you’re using API 2.0 use the FolderItem iterator in a directory and it’s as fast as FileListMBS.

Anyway, that’s a quick and dirty summary of things I’ve learned. Some times it’s good to challenge your assumptions. Happy coding!

AutoComplete Wish

I understand that the future of Xojo is API 2.0.  I have used API 2.0 and while I disagree with some of the naming conventions I can live with it.  I do have a problem with many of my older projects, however.  My older projects, especially the big ones, will most likely never use API 2.0 because it’s simply too big of a task to convert.

To upgrade to API 2.0 for a desktop project I have to change my error handling to go from checking for error codes to handling exceptions.  Any string manipulation cannot simply be upgraded because the older API is 1-based and the newer one is 0-based.  And the sheer number of property name changes is disastrous in some projects.  Converting from Date to DateTime is not a simple replacement either.

That’s not to say that these things are not doable but they are not desirable right now.  And I’d really like to not accidentally invoke an API 2.0 method or property because AutoComplete shows me both.  AutoComplete conveniently shows me the old, classic property/method in red which is great but I have no way of knowing what is new for API 2.0.  Therefor I’d love to have the option to choose what is shown in AutoComplete.

Feedback 57885 Feedback #57885 is just that.  This case is currently ranked fairly high so I’m not the only one that thinks this is a great idea.  The basic gist of it is this:  there is a preference setting that allows me to select what I see in AutoComplete, API 2.0, API 2.0 and Classic, or just Classic API.

In the ideal world (as stated in the Feedback case) this would change the deprecation warnings for API 2.0 if you’ve selected Classic API and it would also switch the local documentation to the proper usage to avoid confusion.

Obviously, Xojo does NOT want to implement this because API 2.0 is the future of the platform.  My argument is that without this mechanism many of us with older, big projects, won’t update our licenses because we can’t/won’t use Xojo with API 2.0.  

This is not a good situation to be in because I feel we’re one macOS upgrade away from disaster.  If you’ll recall before Catalina was released FolderItems were broken in  for a while.  This turned out to be an Apple bug that was fixed.  Another example is the ColorPicker and if you’re using an older version of Xojo you have issues with it that you have to workaround.  What happens with Son of Catalina comes out and something else is deprecated and we *have to* upgrade to newer Xojo.

You might feel like I’m complaining for the sake of complaining.  I assure you I am just looking out for my clients assets and my own hard work.  I can’t justify the cost and expense to upgrade to API 2.0 and I really don’t want to mix and match API’s.  I could use a newer version of Xojo but I just can’t take the chance of using something (API 2.0) that’s not fully proven (to me) yet.  All it takes is one mistake and I have a mad client.

Currently 57885 is ranked 9th.  If you’d like to see it get implement throw your points at it.  What do you think?  Am I agonizing over AutoComplete too much or do you think I’m justified in my concern and request?

May We Live in Interesting Times

I’ve been a Xojo consultant for nearly 20 years.  BKeeney Software has worked on dozens of commercial applications and untold numbers of private projects during that time period.  Consulting is both an extremely rewarding and terrifying business since income can be so variable.  We’ve had multiple employees for years and providing health insurance costs is an expense that’s ever growing.  Having your own business is hard in the best of times.

Over the past twelve months we’ve had two employees leave on their own volition to pursue other employment opportunities.  During that same period the amount of new projects slowed to a trickle and even existing clients haven’t brought in as much new work as they have in the past.  Where once we routinely acquired new projects it just didn’t happen as much in 2019.

Consulting is a weird business where every client wants their project done last week for as little money as possible and then get yelled at when you tell them version 2 is going to cost a lot more money.  As a consultant I’ve had to compromise with what’s best for a project with what the client is wiling to pay for.  It’s a constant struggle and one that I can’t imagine going away as a consultant.  

Earlier this year I was presented with the opportunity to take a full-time job as a senior developer for a company that uses Xojo along with other programming technologies.  I have accepted that position and started with them in a full-time capacity a few weeks ago.

BKeeney Software will continue to support existing clients to the best of our ability.  We will not be taking on new clients and we will have to be very selective in taking on additional work.  We hope the transition is as painless as possible.  When we cannot do the work we will give clients a list of Xojo consultants to contact and we will coordinate with them as best we can. If you’d like to be on that list let me know. Send me an email with your qualifications, types of projects that are in your wheelhouse, and maybe even a client reference I can contact.

Several Xojo developers that know me socially (and knew about the new job) have asked about our products, mainly ARGen, Shorts, and Formatted Text Control.  At this point in time we will continue to offer support just like we always have.  However, we are hoping to find new homes for them and have already reached out to various developers that we feel will treat them and our existing customers right.  Our products were mostly driven by consulting and if we are not consulting we have no need for the products.  Since we know a lot of developers use these products we’d love for them to stay in the community and stay actively developed.  If you are interested in acquiring the rights to any of the products, please contact us.  

I love the Xojo community and its users.  I’ve never found a community that is as passionate about a product as the readers of this blog.  I’m not leaving the community – but transitioning into another form.  My new job uses Xojo. It’s a very large project and is certainly bigger than anything I’ve ever worked on before.

I’m looking forward to working on a set of products with a team of dedicated developers that are working on products that matter while providing a stable work environment for my family.  Certainly the events currently happening in the world do not make consulting any more stable so the timing of this opportunity was exceptionally favorable.

I still plan on doing some blogging about Xojo but it will certainly slow down.  As Web 2.0 and Android hits I will kick the tires and give my opinions of them because…well…I always have an opinion.  🙂

Stay safe and I look forward to seeing you all again at a Xojo event! Happy Xojo coding!

Xojo Web 2.0 with New API 2.0 Event Names

Xojo is usually pretty tight-lipped about future releases with good reason.  We, as users, usually hold them to features that they mention (even when they throw out the usual disclaimers about things might change) so it’s pretty unusual for them to offer any information on future releases.  In the past month or so there has been information leaking out through the forum that says that Web 2.0 is in the later stages of development and they are pretty confident on the feature set.

We already know that Web 2.0 is using API 2.0.  One thing we did not know until recently is that Web 2.0 is going to use the ill-fated new event names that so upset the community in the 2019 R2 release.  We don’t know exactly what the events are going to be in Web 2.0 but we can safely assume the standard Open and Close events are now going to be Opening and Closing.  I (naturally) have several thoughts about this.

First, I think the event name changes are needless.  Opening is not more clear than Open.  Closing is not more clear than Close.  I think the new names are as meaningless as the originals.  So I think using the new events names is a complete waste of time.  Instead of the twenty plus years of institutional memory we all have with event names, not to mention documentation and example code we have to learn new event names.

It won’t matter for Web 2.0.  Probably.  I say probably because we don’t know for sure but the hint is that ALL of the Web 2.0 classes and controls will have new names and thus not affect the 3rd party market as much (although we can presume that anyone selling 3rd party controls for Xojo web has a big task in front of them updating them for Web 2.0).  Does this class name change extend to WebApplication and WebSession too?  Only time will tell.

Another reason why it might not matter is that subclassing controls in Xojo web apps was hard.  Maybe non-existent?  Regardless in our really big web projects we NEVER subclassed web controls.

If indeed every control in Web 2.0 is using a new name it eliminates much of the griping that we had with Xojo 2019 R2 because there is no existing market.  It’s all new there are no naming conflicts.

Since events are added via dialog in the IDE most users will probably just roll with the changes.  Since converting any Web project is a one-way process most users project won’t notice it.  There’s still the possibility of Raising a non-existent event I suppose but I suspect that’s a more advanced feature many Xojo users don’t use and presumably the compiler will give a useful error message.

If the new event names are indeed the future it makes zero sense to have part of the product use Open and another part using Opening.  So this means there are going to be new controls (presumably for desktop and mobile at some point) that have new unique names and therefore use the new event names.  Again, same situation since if they have new control/class names there is no issue with conflicts.  This is similar to moving from the old HTTPSocket to URLConnection with similar functionality but slightly different events.

This last point is the most important one.  If Xojo hadn’t foisted the new events names in the old classes to begin with we wouldn’t be where we are at today.  I still think the new event names offer zero clarity from the old names, but whatever.  I’m just a user, don’t work for the company, and I’m not an MVP so my opinion doesn’t matter.

Okay, Xojo users.  What are your thoughts on using the new event names in Web 2.0?

One last random thought:  Because Web 2.0 sessions have been added at the Xojo Developer Conference (a.k.a. Xojo.Connect) I’m guessing that it will be released as a beta during the conference to attendees.  I am not planning on attending so you’ll have to get your news elsewhere.  This will be the first conference I’ve not attended since 2004 or so.  Hope everyone has fun and gets a lot of useful information out of it.

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?