Xojo 2019 R2: API 2.0 is Here

Xojo 2019 Release 2 arrived this week, and to say that this is a massive release would be an understatement.  Among a large number of bug fixes and IDE enhancements is the first release of API 2.0.  With every release I say that you should test your projects thoroughly, but in this case it needs to be mandatory.

API 2.0

API 2.0 is Xojo’s latest attempt to make the framework consistent across all the classes and should be easier to learn and use than the old framework.  The properties, methods, and event names of practically every single class have changed.  Some have changed in subtle ways, and others in a bash you over the head fashion.  What might be even more important is that classes that used to set an error bit or error code will now throw an exception.

Some of the most basic things in Xojo have changed.  Declaring a variable has changed from using the Dim keyword to the new Var keyword.  Declaring an array is the same but resizing it is now accomplished like this:

//Declare the array

var arNames() as string

//Set it to a new size

arNames.ResizeTo(SomeIntegerValue)

//Clear the Array

arNames.ResizeTo(-1)

In various conversations Xojo has claimed that many users new to Xojo are confused about declaring variables.  I don’t claim to know a lot of other languages, but the few that I’ve looked up don’t appear to be any more helpful.  Looking at JavaScript and Swift, neither requires the data type when declaring a variable.  With no functionality enhancement this seems like a change for the sake of change.

Every Window and Control that comes with Xojo 2019 R2 has new events.  Open, which admittedly can be confusing, is now replaced with the equally confusing Opening event.  Close is Closing and so on.  I have yet to find any direct mapping document of old events to new events and that’s a crime.  

A complex control like the Listbox has dozens of events, properties, and methods and nearly all of them are renamed.  Some make sense.  ListBox.ListCount is now ListBox.RowCount.  But ListBox.EditCell is now ListBox.EditCellAt.  To append a row to a Listbox you still use ListBox.AddRow, but to insert a Row you substitute ListBox.InsertRow with ListBox.AddRowAt.  I simply don’t see why AddRowAt is easier to remember than Insert (I could argue that InsertRow makes more sense).

Some changes I strongly disagree with.  For example, Arrays in the old framework were simple enough to add items to:

dim arMyArray() as integer

arMyArray.Append 1000

arMyArray.Insert 0, 2000

With API 2.0 the Append and Insert methods are replaced with AddRow and AddRowAt.  Again, one can argue that removing Insert and replacing with AddRowAt is simply a poor use of the English language.

Pre-API 2.0 Projects

The good news is that existing pre-API 2.0 projects will work with only a few modifications.  In our projects (Task Timer, Shorts, ARGen) there were little to no changes required to get them to compile in R2.  And the good news is that you can continue to use the old API in R2.  The Code Editor AutoComplete will show you the old API and the new API with the old API call in Red and show you the new API 2.0 method or property.

Starting a new project in R2 will only show you the new API and events.  Certainly one of the drawbacks is that Xojo projects created in R2 are not backwards compatible.  Xojo has never really guaranteed that newer versions would be compatible and this is one of those cases where it’s simply not possible (theoretically if you never implement any events it will work).

My advice: Treat R2 with kid gloves and make backups of your project files before you play with it.

Events

Let’s talk about events for a bit.  I’ve already hit on the Open event that is replaced with Opening and Close that is now Closing.  I find nothing wrong with the new event names, per se, but anyone with an older project, or someone taking an older class and putting it into R2 must be extremely careful. The old Open and Close (and other) events will fire as expected – until someone implements the new API 2.0 event like Opening.  Once you do that the old event no longer works.  This has the potential of really messing with legacy products that use the old Events and new users not knowing the difference and implementing new events and crushing functionality.

Frankly I find events to the most problematic part of API 2.0 since I, as a provider of 3rd party code, can’t enforce that a Xojo developer use the new or old events.  It’s going to be a nightmare for the next couple of years (maybe forever?) as new people find old classes and implement them in their new R2 projects.  Events cannot be coded out with #if statements.  There is simply no way to control which events to use in a mixed environment.

If you’ve created your own control subclasses with custom events let’s hope you don’t have naming conflicts with the new event names.  The only way to solve this is to change your Event definitions in a pre-API 2.0 version of Xojo.

String Classes

Despite being a great idea, the Text datatype from the Xojo framework never really caught on.  As part of API 2.0 many of the Text methods have been brought to the String datatype.  As with all the other classes nearly every method and property name has changed in some way, shape, or form.  

The biggest change, and perhaps the most problematic, is that the string functions are now zero-based.  The first character of a string is zero and no longer one.  The InStr method has been replaced with IndexOf (bad name in my opinion) and instead of returning a zero if the search string is not contained it will return a -1.  Don’t get me wrong, this is a good change in the long run, but when developers are converting their projects from pre-API 2.0 things like this are going to bite a lot of developers as it’s not a direct replacement.  You can’t just simply use IndexOf to replace InStr because it will break your code.  Expect some grumbling about this from the greater community.

Date and DateTime Classes

Xojo has deprecated (not removed) the existing Date class and has created a new DateTime class.  This is mostly a rehash of the Xojo.Core.Date class but it uses Strings.  The new DateTime class is not a direct replacement for Date since the DateTime class is immutable. In effect if you’re doing any sort of date math you’ll need to use the new DateInterval class.  The DateTime class also does not have TotalSeconds but instead has a SecondsFrom1970 property.  To get a New DateTime you use the Now shared method instead of creating a new instance of it.

FolderItem Changes

The FolderItem class was significantly updated on macOS and uses Apple’s more modern API’s.  This should make file operations significantly faster on newer versions of macOS. FolderItem.AbsolutePath has been removed (it’s been deprecated for a while now).

Because of these changes you really need to be careful with URL Paths with query parameters.  The behavior between R2 and earlier versions of Xojo has changed significantly.

Database Changes

The database classes have some welcome changes that have huge implications.  Besides new classes, methods, and properties for everything to do with the database, any interaction with the database has the potential of throwing an exception.  In the old API you had to explicitly check for the Error property.  Now it will throw an exception that you have to capture and handle.  This is both good and bad.

With ActiveRecord and ARGen we’ve been throwing exceptions for years when we found the database error property to be true.  So not a big change for us, but for anyone that’s ever checked to see if a RecordSet is nil will be surprised when the exception is thrown.  This is guaranteed to get your attention (many people never checked for the db error anyway!) but it will be a pain for many developers. Database code will need to be in a Try-Catch block, and doing this in a proper Transaction will cause some structural changes to your code.  

RecordSets are deprecated.  Long live the RowSet!  RowSets are returned from Database.SelectSQL and instructions are passed through Database.ExecuteSQL.  This is in contrast to the old SQLSelect and SQLExecute methods respectively.  I can guarantee that I will mix the old and new versions up for many years to come.

PreparedStatements are no longer needed as they are built-in to the SelectSQL and ExecuteSQL statements.  You no longer have to Bind the DataType and Value as the class does it for you.  This is similar to what iOSSQLiteDatabase has done for years and hopefully this gives everyone more incentive to use them.  PreparedStatements were a pain to use and this new method is considerably more streamlined.

One word of caution to anyone that uses the MBS SQL plugin:  You must update to the 19.4 version as the database class changes required the plugin to be updated. Older versions of the plugin will fail silently and may cause other plugins to not load properly.

Other Things

URLConnection received some updates.  In Windows 7 and 8 it picks up proxy settings.  It also no longer hangs a Windows application when downloading large files or content.  In Linux a ResponseHeader that no longer exists doesn’t crash the application.  They also made the ResponseHeaders an iterable function allowing the use of For-Each loops.

They (finally) added BeginTransaction to the Database class.  It’s silly that this hasn’t been part of the framework for the past decade.

The Code Editor received some interesting changes.  Pressing Shift-Return on an existing If-Then or If-Then-Else will now break the statement into multiple lines.  On a comment line holding the shift key and pressing Return automatically adds another line of comment.

The Layout Editor has some changes too.  It now has a control to switch between Light and Dark modes.

There is now a number of new Refactoring Tools available and they fixed a number of bugs in the refactoring tools.  They added a new code assistant for wrapping the selected code in an #if XojoVersion block (handy with all the new API 2.0 changes).  The Add Event dialog has been updated to allow adding deprecated events when a checkbox is selected (deprecated events are in red).  In the same light you can right-click on an event in the Navigator and choose to convert it to the newer API 2.0 event.

The FileTypes editor and Associated File Types editor have been combined into a single editor.  File Type Roles have been renamed to None, View, Edit, and Execute.  For MacOS you can set if the File Type is unique to the application.

Catalina may force many developers to upgrade sooner rather than later.  The SelectColor function was updated in R2 to no longer use an outdated API function.  Using SelectColor with an app built before R2 will reliably crash on Catalina.  The only solution is to build with R2 or use NSColorPanel yourself with declares or the MBS plugin.

Documentation

Maybe I’m just an old school person and a curmudgeon but I find the lack of Old to New documentation extremely disappointing.  Xojo has a Deprecated list at https://docs.xojo.com/Category:Deprecated but I find it worthless.  I’d like to look at a single class at a time and have all of the events, properties, and methods showing the old name and then the new name along with any comments.  I realize this is a lot of work but I’m surprised that Xojo didn’t create this documentation BEFORE doing any coding to use as their coding bible. 

Any old example, sample project, old forum post, Google search result is now obsolete.  BKeeney Software’s 65+ hours of Xojo training video that covers a good chunk of the Xojo framework is now practically worthless.  I will be shutting the doors of the training site because it’s not worth my time (at this point) to redo over 200 videos.  Xojo needs to convince me otherwise.

Deprecation Items That Have a Replacement

The Xojo IDE tries to be helpful in converting your projects to API 2.0. There will probably be a handful of things that will flag compiler errors in your pre-API 2.0 projects. If you Check your project you will get a rather large list of items that are deprecated that have a replacement. This list can be overwhelming and I recommend NOT doing global search and replace on these items because the code is sometimes quite a bit different. Good luck!

My Advice

If you have an existing project I would be very carefully with R2.  Sure, try it out on a *copy* of your project, but don’t expect to use R2 right away.  I’m almost sure that there will be changes to fix bugs and strong community objections to certain things.  We already know that Reporting and XML was NOT done for R2 and I’m sure we’ll find other things along the way too.

For developers using R2, please be patient.  Get used to the question:  What version of Xojo did you start with?  The community is going to struggle with the changes for a while and we have no idea that his means.

All in all I think there are some good changes to Xojo 2019 R2 but I also think that there was a lot of change merely for the sake of change.  I’m not convinced that all the changes were for the better.  But really, only time will tell.

The Good

  • IDE received quite a few tweaks
  • Lots of bug fixes and enhancements
  • API 2.0 is mostly consistent with naming (with some oddities for sure)
  • Lots of bug fixes and enhancements
  • Exceptions now thrown instead of having to check for error codes
  • FolderItem significantly upgraded for macOS
  • DateTime added as a replacement for Date class

The Bad

  • API 2.0 is not entirely done yet with more changes to come
  • Change for the sake of change in some cases
  • Exceptions for common and expected errors is not ideal
  • New String methods are not drop-in replacements because they are zero-based

The Ugly

  • API 2.0 event handling prevents API 1.0 events from being raised
  • Documentation woefully incomplete
  • All existing documentation, examples, videos are obsolete

What topics would you like for me to talk about with API 2.0?  What do you like and dislike about API 2.0?

Edit: Fixed some typo’s.

MarkdownKit Review

Markdown is a popular text formatting syntax in use all over the web. Markdown was designed to be human readable in plain text, and formatting parsers are available for many different formats.

There are a few different parsers for Xojo, available in both add-on and plugin format. Garry Pettet provided MarkdownKit for us to look at and review. MarkdownKit is written entirely in Xojo code, is fully CommonMark compliant, and generates HTML.

MarkdownKit is implemented with both String and Text versions, and is designed for both Desktop and iOS projects. MarkdownKit is provided as full source code, and includes documentation as well as examples.

With everything provided, MarkdownKit is very easy to use. It really is as simple as one line. dim sHTML as String = MarkdownKit.ToHTML(SomeMarkdownString) The output can then be passed into an HTMLViewer and displayed. This can all be done so fast you get near live rendering.

The way MarkdownKit renders the input is impressive. A MarkdownKit document is parsed into a syntax tree so that an implementation of the rendering interface can walk the document. What we get from all that is a fast and accurate Markdown renderer. And wow is it fast. The demo application really illustrates the speed of MarkdownKit.

Overall MarkdownKit has proven to be speedy, well documented, easy to use, expandable, and CommonMark compliant. MarkdownKit is a great Markdown renderer written entirely in Xojo code. If you don’t yet have a Markdown renderer in your toolkit, MarkdownKit is a solid option.

More information about MarkdownKit, pricing, and the demo downloads are available at the MarkdownKit Webpage: https://garrypettet.com/xojo-addons/markdownkit

Xojo 2019 R1.1

A dot release for Xojo 2019 Release 1 was released today.  Xojo 2019 R1.1 has several significant bug fixes.  This release is highly recommend for all users.

Perhaps the biggest bug fix is related to ListBox.CellbackgroundPaint and Listbox.CellTextPaint events.  They no longer leak memory 64 bytes of memory each call.

In Windows URLConnection received some attention.  They sped up socket requests and decreased the CPU usage.  Authentication no longer hangs when there is request content present.  The events for URLConnection are no longer re-entrant.  This is fancy way for saying that some events, like PageReceived would get called a lot rather than just once and could cause some issues depending upon usage.

Changing the case of label now changes the text in Windows.  For example if you set the label1.text = “lower” and then tried label1.text = UpperCase(label1.text).

Also in Windows, TabPanels embedded within another TabPanel no fires the Changed event multiple times.

One new thing made it into this build.  iOS projects now add default plist entries for NSLocationWhenInUseUsageDescription, NSLocationAlwaysUsageDescription (for iOS 10) and NSLocationAlwaysAndWhenInUseUsageDescription (for iOS 11+).   These can be overwritten by user plist files.

I am glad to see this dot release version of Xojo.  I know we like to beat up on Xojo Inc for various things but I think they generally do the right thing for the community.

(280)

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.

Conclusions

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!

Xojo 2018 Release 4

Xojo 2018 Release 4 hit the internet this week.  This relatively small (84 bug fixes, 21 changes, 5 new items, and 11 doc and example changes) update is a nice end of year release that may or may not satisfy your Xojo dreams.  Let’s get into the highlights.

Of the new items list the big one is the new URLConnection class.  The URLConnection class works with the HTTP 1.1+ protocol and works with http and https connections.  This is a replacement for the Xojo.Net.HTTPSocket and brings back one of the things many developers missed about the old HTTPSocket class – Synchronous communications – using the SendSync method.  

SendSync is a concession by Xojo with the caveat that the application may appear to freeze while running this method.  The regular, and probably the better, Send method is asynchronous and does not freeze the app.  Admittedly the async way is the better way but for many developers the synchronous method is easier to implement and ‘good enough’ for their use.  Still, consider using the async method.

The Screen class now has the ScaleFactor property.  There are two new global constants: AppSupportsDarkMode and AppSupportsHiDPI  that are pretty self explanatory.

iOS builds now use the iOS 12.1 SDK.  macOS builds now use the 10.14 SDK for 64-bit builds.

There are couple of changes that are noteworthy.  The first being that the Windows IDE can now successfully build large projects for Linux 64-bit and ARM targets (frankly I didn’t know this was a problem but I bet that ‘large’ is the key word).  Any remaining threads are now killed after the app.close event (possibly a reason why some apps in macOS crash after they quit?).  EnableMenuItems no longer fires needlessly on every keypress in Windows.  Lingua and Remote Debugger Stub have been updated to work with Dark Mode on macOS.

There are 84 bug fixes in this release.  The more important ones (at least in my opinion):  The Build folder is properly emptied between build runs.  Remote Debugging to a Raspberry Pi no longer randomly crashes when stopping at a breakpoint.  Browsers that have disconnected from the web app will now reload the web app so they don’t appear frozen.  There are also a couple dozen IDE bug fixes to the Inspector, Navigator, Find & Replace and a number of the editors.

As with any new release you need to thoroughly test your projects before doing a public release.  It was noted during the beta period that the Einhugur Search Control didn’t work properly in Mojave but has since been fixed.  We had one large project not work when remote debugging from Mac to Windows but I haven’t had time to track it down.  If you have found any new issues with R4 please submit a Feedback report right away!

Happy coding!

Xojo 2018 Release 2

Xojo 2018 Release 2 is now available.  This release is heavy on fixes with some for the IDE, for Windows, Linux, and some new features for iOS.  

In iOS, the iOSTable now supports Pull-To-Refresh.  iOSTable now does a better job with variable height rows by setting the UseDynamicHeight property and lets the row height be determined by the content of the cell.  The inserting and removing of rows and sections is now animated if they are in the visible section of the table.  The IOSHTMLViewer is now using WKWebView instead of UIWebView.  A fix to the AutoLayout editor now tries to keep you from making constraints that could cause crashes.

Windows received a ton of love in this release but the biggest change is related to drawing.  Xojo 2018 R1 introduced a new way of drawing in Windows that effectively eliminated flicker but it also severely limited the speed of drawing.  R2 appears to have mostly fixed this issue by calling additional Paint events rather than caching pictures.  As always you should test the Windows versions of your apps to see if the drawing speed is acceptable for you.  Many of the old ways to eliminate flicker actually make drawing really slow now so test, test, test!

Besides the drawing issues there were plenty of other Windows changes as well.  Printing in no longer limited to 96 DPI.  BevelButton, HTMLViewer, Listbox, Xojo.IO.TextOutputStream/BinaryStream, Xojo.Net.HTTPSocket, Sliders, Object2D, OpenGLSurface, ContainerControls, and TabPanels were all touched in this release.

Linux and Raspberry Pi wasn’t ignored in this release either.  BevelButton, Listbox, HTMLViewer, and GroupBox received updates to fix various bugs.  Of note, the HTMLViewer on the Pi no longer hard crashes the application.

A change that could affect some people is that Graphics API now takes Doubles instead of Integers for better precision.  It probably won’t be a big deal for many developers but you will definitely want to try your drawing in non-HiDPI and HiDPI modes to see if anything has changed.  I did a quick test with Shorts, Formatted Text Control, and Tab Control and didn’t notice any drawing glitches so it’s possible that the average developer will be unaffected by it.  

Another graphics change is a new AntiAliasMode property that controls the quality level when drawing scaled pictures.  There are three modes:  Low, Default, and HighQuality.  Default Quality, I think, is simply what we have now.  The documentation (AntiAliasMode is missing from the built-in documentation but is online) is unclear as to how Default compares to Low and High Quality.  Testing should reveal this.  Also unclear from the documentation is how this affects speed but one can presume that High Quality will be a little slower but I have not tested this.

There are two new functions added to the SpecialFolder class.  The new Resources function returns the appropriate platform specific resources directory if it exists.  The new GetResource takes the passed in name and returns the file (if found).  Neither of these new functions are found in either the built-in or online documentation.

As always please review the Release Notes to see if anything affects you or interests you.

Documentation and examples are one of those things that no one likes to do.  But given the audience that Xojo caters to (the Citizen Developer) I am always amazed that things that are added to the framework often don’t have an example project.  I might be wrong (because I didn’t check every single example) but the new IOSTableRefresh and new animations don’t have an example project.  Nor is there anything for the new AntiAliasMode.  

The new SharedFolder.Resources and GetResource methods aren’t in any of the available documentation (other than release notes) but at least Resources is used in the SpecialFolderPaths project.  However, that example isn’t listed in the Release Notes as being changed.

The documentation not being available at release is simply unacceptable.  Each new feature should have an easy to find example project demonstrating its use (preferably available during the beta period too).  I also recommend having a folder for each version that has shortcuts to all of the examples that are new or modified for the current release.  Every release this list changes so the examples list doesn’t get loaded up with folders from old releases.  Regardless, I’m very disappointed the documentation in this release.  Xojo needs to do better.

Anything in this release that you’re happy, or unhappy, about?

Xojo 2018 Release 1.1

Xojo announced the availability of Xojo 2018 Release 1.1.  This ‘dot’ release fixes a couple of glaring bugs that were introduced in 2018 Release 1.  Some of the more important fixes:

  • A NilObjectException caused by an undo in the IDE has been fixed.
  • A regression in the debugger kept some 32-bit breakpoints from working reliably.  The debugger now stops at breakpoints correctly in 64-bit and ARM targets now too.
  • In Windows, if you have a global variable it can now be viewed in the variables pane.
  • The Printer graphics.clip method now works as expected.  If you printed a Shorts document in Windows you would have run across this bug.
  • A host of Windows framework bugs were fixed.  TabPanels now draw properly with proper backgrounds.  TabPanels that contain sliders and scrollbars that caused the tabs to scroll off the TabPanel is now fixed.  The Canvas control now properly refreshes after Scroll is called.
  • iOS projects now compile when it has a launch screen with an image that has no actual pictures in the image.

If you are experiencing any of the issues listed in the release notes you should update to R1.1 immediately.  It’s a shame that it took Xojo nearly a month to get this release out the door.  I realize that XDC causes a huge disruption to their development schedule but the wait for this dot release was too long.

For those of you doing a lot of Windows development, are you still experiencing drawing/speed issues?  Or, have you determined the secrets behind making things better/faster?

Xojo 2018 R1

Xojo 2018 R1 was released today.  It’s been over four months since Xojo 2017 R3 was released in December of 2017.  By any stretch of the imagination that’s a long time between updates.  Let’s start with the big ticket items that you’ll be relatively happy about.  2018 R1 has a ton of bug fixes, enhancements, and new features.  

Windows users will find things to be happy about as Xojo has gone way out their way to reduce flickering issues in the Xojo IDE and in our own built apps.  The magic behind the scenes is not that Xojo is using double buffered windows (or anything like it) but they are now freezing drawing in the window while it’s doing things in the background.  Thus the flicker is gone but at the price of speed.

If you’ve spent a lot of time working around the limitations of control flickering in Xojo, your upgrade to 2018 R1 won’t be a walk in the park.  A number of forum users have done considerable work figuring out the best way to get things to work well together.  The basic premise is that everywhere there is a Transparent, DoubleBuffer, or EraseBackground property you should turn them off.  I’m sure in the upcoming days a more thorough explanation of the best practices will turn up on the Xojo forums.

One thing that might really turn developers off is Feedback Case #51337 where Labels look ‘fuzzy’ and not acceptable to many end users.  This appears to be caused by the difference between the Direct2D drawing engine and the old GDI engine.  Before jumping into 2018 R1 you might want to do some testing to see if this is acceptable to you.

Printing in Windows appears to be better now as you can now print with higher resolution than 96 DPI.

The other big Windows feature to make it into 2018 R1 is the ability Debug and Remote Debug 64-bit Windows applications.  This is a big deal and required that Xojo upgrade the compiler to LLVM version 6.

In late beta testing I had issues with the Remote Debugger (from MacOS to Windows) not dropping down into the debugger and AutoComplete sometimes not working but those appear to be fixed just before the final release.  If you run into issues with either please report them as soon as possible!

The EraseBackground property is now gone for Canvas and Container Controls.  Container Controls have a new DoubleBuffer property that composites the control on Windows and allows for moving/scrolling controls with less flicker.

The Currency datatype is working properly again in 64-bit builds.  In previous builds the Currency comparisons didn’t always work and precision was lost when dividing Currency values.

A host of Windows framework bugs were fixed in the Listbox. The Val function in 64-bit Windows builds now returns appropriate values.  BevelButton captions and menu arrows now work properly when the DPI scale factor is greater then 100%.  Graphics TextUnit.Pixel is no longer treated as Point sizes when the DPI scale factor greater than 100%.  Please see the Release Notes for a complete list of Windows framework changes.

The Web framework received some love too.  The WebFileUploader control works with files greater than 2 GB in size and works with files with ampersands and apostrophes in their name.  It also supports drag and drop and now has a new UploadProgress event.  It also supports file multi-select to allow users to select more than one at a time.  It also has a CancelUpload method and a new UploadTimeout property.

The WebMoviePlayer now uses a native HTML5 video player on supported browsers (I believe this means all of them) and now has a separate Stop method.  Internet Explorer 9 support was removed.  WebMapViewer only calls into the Google Map API once per browser session.

The SQLite library was updated to version 3.22.  One of the big changes is that errors when creating SQLitePreparedStatments now get a more meaningful error messages versus the unhelpful ”unable to prepare” message.  SQLiteDatabase now supports AES-256 encryption.  The SQLiteDatabase now yields to other threads when it’s busy performing a long operation and using the ThreadYieldInterval property.

For many users the upgrade to 2018R1 will be a no brainer.  However, those that have a complex UI should do some testing in Windows to ensure that drawing speed is still acceptable.  Some beta testers found that the tradeoff of being flicker free was not worth the slower rendering speeds.

The Debugging of Windows 64-bit applications is a much needed and welcome feature.  Without much time to see it working (properly) I can’t give much of an opinion of it.  The compiling speed of 64-bit apps is very slow and it appears that incremental compiling is off.  I would expect the entire process to get better over time.

With this major milestone out of the way I hope we see considerable progress on Interops, creating plugins from within Xojo, Android, and Web 2.0 in the next couple of releases.  I’m sure we’ll find out more next week at XDC.

What excites you in 2018 R1 and what gives you some concerns?

Xojo 2017 R3

Xojo 2017 Release 3 is now available.  As with all Xojo releases there is a mix of new features, big and little changes, and a host of bug fixes.  I’ll highlight some of the big items.  See the release notes for the complete list.

Perhaps the biggest change in Release 3 is that this is the first release where the IDE itself is 64-bit.  For macOS this is the only option.  In Windows the installer will choose the proper version for you system.  For Linux, the IDE is only 64-bit and will not run on 32-bit systems (note that it can still created 32-bit executables).

This is a major milestone for the Xojo IDE and is the culmination of many years of hard work by the developers.  It’s hard to imagine the work involved in taking a large product, like the Xojo IDE, that once assumed everything was going to be 32-bit only and rewrite practically every class, method, and function to ensure it works properly in 32-bit and 64-bit on Mac, Windows, and Linux.

So what is the deal with 64-bit? It lets the IDE use a lot more RAM.  In Windows especially this has been a limitation.  Some processes in the IDE, and in our built applications might be faster (emphasis on the might).  And since most computers are shipping as 64-bit these days it seems archaic to keep using 32-bit applications and in some cases for Linux it’s really hard to run 32-bit apps on a 64-bit machine.

One thing that changed because of the move to 64-bit is that the IDE Auto Saves the project before a debug run in a different way from previous versions.  Prior to R3 it used memory blocks to save this data in temporary files in case the IDE crashed.  In R3 it still saves but it’s using a much slower method.  It’s a long and drawn out explanation but it’s because of memory fragmentation that can happen even in 64-bit builds.  On very large projects this can take a LONG time and can make the IDE look like its stuck since there is no visual feedback of what it’s doing.

If this is a problem for you there is a way to get the IDE to NOT AutoSave the project before the Debug Run.  Warning:  This is for advanced users that understand the implications of doing this:

Confirm that Xojo is closed. You can set ‘Autosave Allowed’ to false the following ways:

macOS:

Edit the Xojo Preferences ( ~/Library/Preferences/com.xojo.xojo)

Add a key with either a true or false value

<key>Autosave Allowed</key>

<false/>

Linux:

Use the same key entry style as macOS inserted in ~/.Xojo.Xojo

Windows:

Use regedit to edit HKEY_CURRENT_USER\Software\Xojo\Xojo

Add a new DWORD value with the name “Autosave Allowed”

a value of 0 is false

a value of 1 is true

Another issue for 64-bit builds is the Currency data type.  According to long time Xojo developer Kem Tekinay using Currency is not recommended in 64-bit builds due to comparison issues.

The IDE now cleans up properly after a debug run.  This should eliminate the issue with the IDE showing a file IO error when trying to do multiple debug runs.

Layout Editor

Dragging IDE windows around with thousands of controls on the layout renders better now.  It is still recommended that you use container controls to limit the number of controls on each window.

Report Editor

Fonts on reports, especially in 64-bit builds, are now rendering at the proper size.  The Report Editor now honors locks as it should.

Code Editor

The Code Editor now highlights the lines of code blocks.  I’ll be honest, this is a totally unnecessary bit of fluff in the code editor but after using it for a few weeks I find that I like it.

The Automatic Code Reformatting now takes effect when you click away from the line of code.

Remote Debugger

The Remote Debugger Stub was rebuilt using 2017 R2.1 and thus has a speed boost.

The Mac Remote Debugger is now 64-bit and can run 32-bit applications as well.

64-bit and ARM Console debugger stub’s are included.

Lingua

Lingua now has a scripting folder where you can run XojoScript to manipulate the translated text.  This is really useful in post-processing where if your translator puts quotes around everything, or likes to put the source and translated text together.  Presumably an enterprising developer could use XojoScript to connect to a translation service.

ARM

XojoScript now works on Linux ARM builds.

Windows

64-bit Widows apps now display manifest settings in the advanced tab of Windows build settings.  This allows you to set Windows versions and privileges for your app.

iOS

Support for iOS 8 and iOS 9 has been dropped.

Xcode 9 is now supported as well as 64-bit debugging.

Web

Internet Explorer 10 support has been deprecated.

A number of bugs in the Web framework have been fixed.

Conclusions and Opinions

All-in-all, this release is an important one since the road to 64-bit has been a long and arduous process.  Xojo Inc. has missed on a number of promised deadlines this year and while some of them were under their control – many were not.  Let’s hope that 2018 is much kinder to their schedule.

I would expect the slow Auto-Save that popped up with the 64-bit IDE to be addressed at some point.  One personal opinion on this that irks me is their temporary fix for ‘advanced’ users.  Come on.  Really?  Stop treating us like children.  I don’t know about you, but in my 16 years of using Xojo I’ve only tried to use the AutoSave feature a handful of times and I can only think of one case where it actually saved me any time.  Keep in mind that you might very well never experience the issue if your project is small but I tend to have big projects and it’s a noticeable lag.

I did not like code block highlighting in its debut.  I felt that it was a complete waste of programming time.  After using for a few weeks it’s not that bad but I’m not sure it’s all that useful either.  I suppose if you have have six or seven layers if nested code it can be helpful but I tend NOT to do that.  It also might be really helpful with really long methods, and again, I tend not to do more than a page of code (I hate scrolling).

As with all Xojo releases it’s important to test your projects to ensure everything works as you expect.  I would expect a few things to shake out of the 64-bit IDE as more developers bang on it.  Xojo is a big project and the beta testers (myself included) can’t hit every single feature.  I’m not sure if I’d expect a dot release from R3 but I also wouldn’t bet against it.

Give me your thoughts!  Do you like R3?  Is it stable and reliable?

Xojo 2017 R2.1 and Updated Roadmap

I’ve had a hellacious travel schedule the past six months so I apologize that I’ve not been up to snuff on Xojo news. Last week Xojo 2017 Release 2.1 was made public and earlier this week Xojo CEO, Geoff Perlman, penned a blog post about the short-term roadmap for Xojo. Let’s dig in!

First, the 2.1 release has a mere 16 bug fixes in it. This dot release fixes some critical Linux, and Windows bugs. A few IDE bugs were addressed and the PostgreSQLDatabase plugin was updated. Many of these bugs won’t affect everyone but it’s definitely worth upgrading from R2 if you have not already done so.

Now on to Geoff’s short-term roadmap. You can read the entire blog at https://blog.xojo.com/2017/09/19/the-short-term-xojo-roadmap/. To summarize it in a nutshell: 64-bit is taking them longer than expected.

To this I say, ‘Duh’. Anyone who expected 64-bit to be done by this time hasn’t been around very long. Xojo has consistently blown their estimates for most (all?) of their big projects. The transition to Cocoa from Carbon took a lot longer than originally announced. iOS took longer than expected. The introduction of the Xojo IDE from the Real Studio IDE was also delayed (as a side note I’m still amused at the accusation that I personally caused a 6-month delay in the Xojo IDE due to a blog post).

The point isn’t, ‘Oh my gosh, Xojo has yet another delay’ it’s that Xojo is very bad at estimating this stuff. Some of this is on them but some of it is beyond their control. Supporting mac OS, Windows, Linux, iOS, Raspberry Pi, desktop, console, and web apps is a mammoth undertaking. I am constantly amazed at the magic Xojo performs without my knowledge. To me it ‘just works’.

Apple, bless their hearts, changes things on a whim every year at a minimum (sometimes even more often than that) and causes Xojo to play catch up. And they usually do this with little notice. The current change being that the iOS Simulator will no longer support 32-bit apps so guess who has to scramble to make it work now?

Linux distributions seem to change daily. Xojo has to scramble to catch up with those changes too. They recently updated Xojo to use GTK3 and that was a big deal. They sort of had to do this upgrade because GTK2 was pretty long in the tooth. I can only imagine the internal efforts they did for testing.

Windows doesn’t change much for better and worse. The technology from ten years ago still works but that’s not necessarily the best ‘modern’ approach for Windows. Many users complain about flicker when windows are resized. This is a valid complaint but because Windows does not double-buffer their windows like Mac and Linux the older Win32 controls flicker like mad under many circumstances.

Regardless, 64-bit is the roadblock for other things. If you were hoping for Android, interops, or plugins compiled in Xojo to be released in 2017 you’re out of luck. This is what happens with a small development team. There simply isn’t enough man-hours to work around delays in some projects. This happens in ALL software development products but with a small team this impacts everything.

The only bit of good news from Geoff’s blog post is that the Windows framework is getting a big update. This update will ‘dramatically’ reduce flicker according to Geoff. No word on what exactly they’re changing though a thread on the forums from Aug 9 might give a little clue. Changing transparency seems like a little thing but perhaps they plan on implementing a double-buffering scheme. Until we find out more it’s not worth speculating. It seems like this new scheme might make it by the end of this year. So either this has been in the works for a long time or it’s not huge from a coding standpoint.

Promising services based on a product feature that doesn’t yet exist is dangerous. If you were promising Cocoa, iOS, or 64-bit versions before they were actually released you did your customers a disservice. I remember one XDC where a database ORM (Object Relational Model), similar to ActiveRecord, was shown with a lot of interest by those attending. I’m still waiting on it. The lesson is to not depend on vaporware!

So what are your thoughts on R2.1 and the Short-term Roadmap?