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?

Xojo 2017 Release 2

Last week Xojo 2017 Release 2 hit the download servers. This release has the usual mix of new, changes, and bug fixes. At first blush it doesn’t seem like there is a lot to mention but there is, but I’ll get to that in a minute.

Before we get into the highlights it’s worth mentioning, again, that R2 does not have 64-bit debugging for Windows. As Xojo mentioned in their blog post (http://blog.xojo.com/2017/07/26/the-best-laid-plans-64-windows-debugging/) the LLVM compiler and toolset just wasn’t ready to be included in R2.

Despite the lack of a 64-bit debugger for Windows a number of things were corrected in 64-bit Windows builds. Icons are now applied correctly and they also show the correct version information. The 64-bit MS SQL Server database plugin now works when compiled on the Mac. Game Input Manager also works in 64-bit now. Images assigned to an ImageWell are now drawn properly.

Also related to 64-bit builds, the Split and Join functions for Unicode strings is much faster and Replace and ReplaceAll behaves like the 32-bit versions. Exceptions no longer leak memory. Virtual Volumes now work. Copying a picture to the clipboard now works. XojoScript is now available in 64-bit builds.

Linux GTK3. See Xojo blog post (http://blog.xojo.com/2017/08/15/goodbye-gtk-2-hello-gtk-3/) detailing some of the changes. The switch to GTK3 was necessary for HiDPI support and now scales automatically on integral scale factors (i.e. 1x, 2x, 3x, etc). This also lets child controls clip properly on parent controls whereas they did not always clip properly in prior versions.

Be aware, though, that this switch may affect how your controls draw. While it’s always been true that default control sizes are bigger in Linux you could sometimes cheat and use the open events (or subclass the controls) and make them slightly larger in Linux and perhaps make the system font a little smaller and things would look good enough to not require a bigger UI change. With this switch to GTK3, however, it seems like some controls, PopupMenu and Pushbutton come readily to mind, in that their caption location is definitely lower than the prior version thus making them look odd without more work. For me, what worked in R1.1 just doesn’t look good in R2.

This change begs the question that if we could make a Xojo theme for Linux that would make control heights smaller, text sizes smaller, and change the caption locations to make this a non-issue. Perhaps someone with more knowledge about Linux themes could answer that.

A few other things that might ruin your day in Linux is that not all Linux distributions now allow you to remove the border of TextFields. It wouldn’t surprise me if additional issues are found in GTK3 as time goes on.

iOS has a couple of important changes. The first is that the AutoLayout Priority property in prior versions was calculated on its own. In R2 new constraints get the ‘Required’ priority. Any existing projects should get thoroughly tested on multiple sized devices to make sure nothing needs to be fixed. In our own testing we had to simply change the priority to Required to fix any issues.

Another iOS change that may affect you is that setting the CopyFileStep to the “Frameworks” destination now properly creates the Frameworks folder inside the iOS package and puts the files there. Before you had to create a manual directory for it to work properly.

Another nice fix is that a numeric suffix is no longer added to copied iOS controls unless they need it. This was an annoying bug. Not hard to fix but annoying nonetheless.

The web framework received some attention in this release as well. The WebPage width and height properties are now correctly updated before the Shown event is fired. A number of WebMapViewer errors were fixed including an annoying JavaScript error on the first refresh and where it would fail if there was more than one instance used in the app at a time.

The Session timeout now takes touch events into account when figuring out the last interaction with the app. In addition to that, web apps now try to reconnect if they’ve lost connection to the web app and will continue to do so for three minutes or until the user navigates away from the disconnect screen.

The Listbox control received some updates. For Linux, HelpTags are now positioned properly and in Windows they disappear properly when the mouse leaves the control Also in Windows the endcap is drawn correctly and headers no longer flicker when hovered over by the mouse or when clicked on.

A regression was reported for R2 that affects dragging items to the Listbox. In Windows the X & Y coordinates are incorrect. This was reported in Feedback 49190.

New Drag events were added to the Listbox. Except for a jumbled paragraph in the release notes I’m not sure anyone would notice. I would spend more time talking about it but as far as I can tell these are not documented in the Language Reference, either local or online and there is no example. I find it inexcusable to have a major change to such an important control not be documented. This seems like it should automatically make it into the documentation. Do better Xojo!

The IDE received a bunch of bug fixes and changes. New items in the Menu Editor no longer ‘fly in’ and arrow keys work now. Long error messages are wrapped and row heights adjusted in the error reporter are adjusted as needed (as a side note does this forebode variable height list boxes?) Recent Items in the Project Chooser now show size, date created, and date modified when possible. Pressing the Escape key now acts as a “Revert Now” to changes.

It also appears that a regression bug was introduced in Raspberry Pi. Button.Action events don’t fire if using a touchscreen. They appear to work properly when using a mouse. Feedback 49221.

As always, look through the release notes to see what else has changed. It’s also a good idea to test your applications thoroughly when upgrading to a new version.

Xojo 2017 Release 2 was chock full of new things and changes. I hope a dot release is issued to fix some of the bigger regressions. Up next is 64-bit debugging and remote debugging, the new plugin format, interops, and Android. Think they can get it all done in 2017?

Sorry for the delay in getting this out. Those pesky clients sometimes want on-site help and the last thing I feel like doing is writing after a long day of coding.

 

Xojo 2017 Release 1.1

Xojo 2017 Release 1.1 hit the web today.  This dot release contains some very important Windows framework bug fixes related to printing and is recommended for all users.  There are a few other changes as well.

For those that are trying to print reports in Xojo this release fixes some critical bugs.  First, the Printer.Landscape property is now honored whereas before it used the default printer orientation.  Second, the PrinterSetup.Setup string is now built and restored properly and works when set.  These fixes now allow reporting tools like BKS Shorts to print properly in landscape mode when restoring the PrinterSetup.SetupString.

A couple of exceptions were fixed in the IDE.  Toggling the line number display in Windows no longer disables the cursor.  You can now toggle the line numbers in IDE scripts.  Duplicating an instance of a container control no longer create an invalid control set.

It is important to recognize the value of this dot release.  For many developers this isn’t an important release but for those of us that rely on printing this was a big deal.  2016 R4 broke printing almost entirely and it was mostly corrected in 2017 R1.  Each release of Xojo brings new features and many bug fixes it’s often very difficult to revert to an older version.  So kudos to Xojo Inc. for doing a dot release.

Xojo 2017 Release 1

The road to 64-bit took another step forward today with the release of Xojo 2017 R1.  This important release let’s you do 64-bit Remote Debugging for some targets with some important caveats.  It also adds the ability to Remote Debug Raspberry Pi applications.  And, as with every Xojo release there are a mix of new features and important bug fixes.

64-bit Remote Debugging

2017 R1 lets you remote debug 64 desktop, console, and web applications on macOS and Linux assuming that neither one uses XojoScript.  64-bit XojoScript is still missing in action which is preventing the IDE itself from being 64-bit.  I believe this is scheduled for Release 2.

Missing is the ability to remote debug 64-bit iOS, and 64-bit Windows applications.  Presumably iOS shouldn’t take long since macOS is already working.  From what I gather the LLVM compiler for Windows isn’t as far along as macOS and Linux so it’s taking longer to get working.

The Remote Debugger Stub has been updated to version 2.1 and now has 32-bit and 64-bit versions for Mac, Windows, and Linux, and a Linux ARM version for the Raspberry Pi.  The 64-bit version can switch between 32-bit and 64-bit correctly depending on the target setting in the IDE.

Major Changes

One of the important updates to the web framework is causing major issues with HTMLViewer controls that depend on StatusChanged events.  The web standards group decided that the StatusChanged can no longer be fired via javascript any more and the updated WebKit engine in R1 breaks code that depended on the old functionality.  For developers using Tim Parnel’s HTML Edit you will have to wait for an update before upgrading to R1.

The web framework now allows developers to use HTML in many of the controls.  WebLabel, RadioGroup, Listbox, Toolbar items, and SegmentedControl can use HTML tags in their captions.  Example:  Label1.Text = “This is a line with <raw><b>bold</b></raw> text in it.”

The Listbox has been updated for all desktop targets and now allows you to customize the disclosure widget.  This seems like an odd change.  Could this be prep work for something in a future release?

SSLv3 on Xojo Cloud services is deprecated and will be disabled on all servers in summer of 2017.

One of the new options in the Preferences is to force Standardized Format after every line.  This mirrors the contextual menu command Standardize Format which looks at the current selection and changes the case of every Xojo keyword to match it’s default.  So if you typed ‘recordset’ it will change the case to ‘RecordSet’.  It does nothing for your own variables (which would be more useful, in my opinion, and it looks like a future release may allow for that).

Also new in the preferences is the ability to change the keyboard shortcuts of all of the menus in Xojo.  If you don’t like the Remote Debugging key combination you can change it to something else.  One that I think I will change is the Build (command/control B) to something (perhaps command-option-B) since I often accidentally build once or twice a week when simply trying to paste code.

Bug Fixes

A number of Windows framework bugs were fixed.  Probably one of the more important ones is with Xojo.Net.HTTPSocket.  The socket events are now called when it is created within a thread.

Another big Windows bug fix is in Direct2D printing (broken in 2016 R4).  Font sizes were incorrectly reported by the graphics object and thus caused all printing to be messed up.  BKS Shorts (our reporting tool for Xojo) works properly in 2017 R1 when printing in Windows.

Windows received a number of important HiDPI updates.  Note that the application icon for 64-bit builds is still not being set.  One workaround is to set the associated icon via your installer.  If you want an example of how to set this via an Innosetup script, let me know and I’ll share it with you.

The IDE received a really big batch of bug fixes in R1.  The amount of them makes it impossible to list them all here, but one that’s been around for a long time is that ellipses (…) are no longer saved when creating the method signature.  That bug hits me every now and then.  For the entire list of IDE bug fixes, please see the release notes.

Conclusions

The road to full 64-bit compatibility is happening incrementally.  R1 is another step in the journey and it’s nice to see progress.  It is my hope that 2017 R2 will have Windows and iOS 64-bit remote debugging (in the iOS Simulator – I doubt remote debugging on an actual iOS device will ever happen).

Xojo has said that the Windows IDE will require 64-bit at some point in the future (even though it will still be able to build 32-bit Windows apps) and that future might be sooner than we expect.  I’m curious on how many people think this is a good or bad?

This release has some nice goodies in it.  The remote debugging for the Raspberry Pi has been awesome.  I’m working on a project right now that advanced in a number of days what had taken me months of work to do before.  The work in Windows to correct the Direct2D printing issues is most welcome and the number of HiDPI fixes is nice too.

I’ve been using R1 in regular production work for a number of weeks for macOS, Windows, Raspberry Pi, and iOS development and I’ve been pretty happy with it.  It’s been stable and I have no complaints with it.  The only thing I didn’t spend any time on in this release cycle was web.

Anything new in 2017 R1 that you are happy about?  Anything that disappointed you?

Xojo 2016 R4.1

Xojo 2016 R4.1 was released today.  The 4.1 release mostly contains Windows fixes related to the switch in drawing engines.  Gone is GDI Plus and Direct2D is now used instead.

GDI Plus wasn’t only deprecated but removed so that is a little different than most Xojo releases.  It is highly recommend that you test your Windows apps thoroughly before release.  It’s also recommended that you test your 64 bit builds as well since it’s a newer framework and has received less attention.  Just today I found out that SegmentedControls don’t draw right in Windows 64 bit builds.  Feedback id 46268

As always, take a look at the full release notes for pertinent information.

Monkeybread Software released version 16.5 of their plugins today http://www.mbsplugins.de/archive/2016-12-12/MBS_Xojo__Real_Studio_plug-ins and is recommended for all users.  Einhugur http://www.einhugur.com has released a number of updated plugins for R4 and has indicated that more are updates are coming.