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?

Remote Debugging Enhancement Idea

Remote Debugging in Xojo is perhaps one of my favorite features in Xojo because it lets me work in the environment of my choice (macOS) and run it on any Windows, Linux, or even another Mac on my network, or in my many VM environments.  One of the things that’s always bugged me about remote debugging is the cycle time.  Every time you do a remote debug the IDE sends everything (executable, libraries, resources), again, to the remote debugger.  Even a simple change requires that the entire package is transferred to the remote debugger.  Every.  Single.  Time.

Xojo improved the cycle time for deploying web apps to Xojo Cloud in 2016 Release 4.  They did this by caching the framework and plugin libraries on the Xojo Cloud server.  When connecting to the Xojo Cloud server it tells the IDE what frameworks and plugin libraries it has and the IDE then decides what to upload.  So your first upload may take four or five minutes but subsequent uploads using the same version of Xojo take considerably less time.  In my case it’s about a minute.  It’s a welcome speed up.

In remote debugging, large projects can often take a LONG time to send simply due to their size.  I find myself debating on whether to install the IDE in that environment (along with prerequisite plugins), or to simply wait through the remote debug cycle.  Sometimes it’s a wash, but, I’ll be honest, it’s irritating to spend the three minutes transmitting to the remote debugger only to have to quit almost right away and change a label or a single line of code, only to have to sit through the transmit time again.

Why can’t they do the same thing for Remote Debugging that they did for deploying to Xojo Cloud?  Think of the time savings this change could do for someone that does a LOT of remote debugging like I do!

Time savings aside, there ARE some drawbacks.  The first is that the Remote Debugger becomes a much more complicated mechanism than it already is.  Since much of the code is (presumably) portable from Xojo Cloud to the Remote Debugger this might be a moot issue.  However, converting from whatever they’re using on Xojo Cloud (presumably Xojo) to desktop use may not be trivial.  It’s hard to say without asking that question.

Secondly, it would have to store all of these libraries and frameworks in a cache and then what would you do for cleanup?  When it quits delete these caches or keep them around?  I could argue for both ways.  Perhaps that’s a preference setting with maybe a quick calculation on how large the current cache is?

Third, it distracts from 64-bit Remote Debugging.  Maybe.  If I had the choice I’d love both, but if it meant delaying 64-bit for six months I’d rather have 64-bit now.  This is a wish list item, after all.

I created Feedback ID 46848 to get this idea into circulation.

What do you think about this idea, Xojo Developers?  What other pain points do you have with Remote Debugging?

Remote Debugger Issue

One of the changes in Real Studio 2012 Release 2 was an improved Remote Debugger Stub.  It compresses the files it’s going to transfer which results in a significantly faster transfer to the remote machine.

I’ve been happy with it until today when I kept getting this error when trying Remote Debug into Windows in VMWare on my machine.

VMware FusionScreenSnapz001

 

Not a very helpful error message.  This occurred as soon as the first data packet reached the Debugger Stub.

After banging my head of against the wall for about an hour (and starting to panic a bit because of a deadline) I started poking around.  The stub has worked for me, without issue, for years.  Why now?  What changed?  I tried using an older stub, older IDE versions, and all sorts of things.  Since I had the older one, newest one, and even a new beta version I had renamed the folders so I could keep them in one folder.  Last week I consolidated and moved folders around so I could manage them batter.

Have you guessed what the problem is yet?  I finally went to options and that’s where I discovered that the Download Location I was putting the files into no longer existed.  A simple change fixed the error and I was able to use the Remote Debugger in Windows again.

Feedback report <feedback://showreport?report_id=23508> was submitted.  Ideally the Stub should check the location before a debugging session starts or if the location doesn’t exists uses a temporary location.  I suspect this one will get fixed rather soon.

So, there you go.  If you’ve been banging your head up against a wall trying to get Remote Debugging to work, you might want to check the Options/Preferences and see if the Download Location exists.  Hopefully this saves someone, somewhere along way, some time.  Happy Coding!