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.

 

Software Development is Fluid

Software development is fluid. Some bug fixes and feature requests that seem simple are often not so simple, or, take a lot longer than originally thought. Some that seem like they’re hard are not, or, take practically no time at all. What’s worse, is that sometimes you don’t know what the level of effort is until you start the work.

Historically, the only way to know what future feature sets will be in Xojo is attend a Xojo developers conference where the CEO of Xojo, Geoff Perlman will sometimes tell us what’s coming up. These announcements are almost always preceded with a “we expect to release that feature in this timeframe.” It’s smart because he knows that software development is fluid.

The problem is that what we hear is, ‘Release X will have this feature.’ We hear a promise despite all the hedging made by Geoff. Like every user I want that feature now and there are times that I need that feature to sell some work. I think it important to remember that when selling any work you have to use the current (and proven) technology instead of what’s coming up.

64-bit Remote Debugging in Windows comes to mind. Geoff at last years XDC said that in the first quarter of 2017 Remote Debugging will be available across all platforms. In Berlin in May he said Release 2. Well, as they said in their blog post at http://blog.xojo.com/2017/07/26/the-best-laid-plans-64-windows-debugging/ this isn’t going to happen for 2017 Release 2. Apparently the LLVM compiler and toolchain isn’t ready for primetime yet. So instead of giving us a buggy (and probably unusable Remote Debugger) they pulled it.

I understand and applaud the decision. Software development is fluid and some things are out of their control. Since Xojo is not in charge of the LLVM compiler and toolkit for Windows they are at the mercy of other developers. It stinks but that’s just the way it works.

I know that some of you will jump on the ‘let’s criticize Xojo’ bandwagon and you have every right to do so. However, keep in mind that they do hedge their announcements with ‘we plan’ or ‘we expect’ to do x by this time or this release. If we want to get any information out of them about future plans we need to cut them some slack. They have zero obligation to tell anyone about their long-term plans.

What Xojo does is magic. For a vast majority of Xojo users it ‘just works’ on every platform they target. It’s been a long time since I’ve had something work on one platform and not on another (that wasn’t my own fault). Think about it: Desktop, Console, and web apps for Mac, Windows, Linux, and Raspberry Pi just work with a simple checkbox. iOS applications are different and use the new framework but I expect Android (promised by end of year) to be very similar (if not identical in most respects). And let’s not forget 32-bit and 64-bit apps just work too despite 64-bit being a relatively new target.

Software development is fluid and every year Xojo has to deal with whatever Apple, Microsoft, Raspberry Pi, all the Linux distributions, and all the browsers throw at them. I’d say they’ve earned some slack from us users. I’d rather have a release that works than one that doesn’t (I remember some that didn’t work).

Does this mean we should stop criticizing Xojo? Pft. Please. The day I stop criticizing Xojo is the day I stop using it. It is our responsibility to keep reminding them of what we need. A long standing criticism are bugs that have been reported and have been around a long time. But yet every release has many dozens of fixes so they do fix a lot of bugs. The one’s that are hard to excuse are new features that have obscure bugs that last multiple releases.

Some of the criticism must be on us users. We don’t always report bugs. Never assume someone else has reported it. Always try to give them an example project demonstrating the bug. Xojo has some responsibility for this, too, as Feedback hasn’t always worked for some users. This is part of the give and take of a software development tool company and its users. We need them and they need us.

So yes, it stinks that 64-bit Remote Debugging isn’t available for Windows yet. And you’ll note that they’ve not said when it will be available. We can hope that it will happen for Release 3 but until the next beta round we won’t know for sure. I expect that all of their other plans for 64-bit are probably delayed too. A 64-bit IDE might be a few releases away. We don’t know what this means for the new plugin format, or Android, either. Software development is fluid so go with the flow until we see something solid.

Happy coding!