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?

Recharging the Battery

One of the ‘joys’ of having my own business is that I’m always on-call and there are times I’m answering emails on a Saturday night.  Most of the time, it’s no big deal but it can become exhausting without a break.  This is why I need to take time off and recharge my batteries.  So should you.

Carol and I did that last week with a vacation in the Caribbean.  We had a lot of fun and got a chance to recharge our batteries and get away from work (and US politics).  And even though we weren’t technically working (I consider coding to be the real work), we did talk about our business and those things we are grateful for.

One thing we are extremely grateful for is the fact that we can take off for a week without feeling guilty.  That got us thinking on why is it so hard for consultants to take time off.  It’s not too hard to figure out but here are a few items from our list (sadly the list got a Bahama Breeze spilled on it and thus couldn’t be saved for posterity, but here’s what we remember).

If you’re not working you’re not making money.  So true for consultants, but my advice is to try to develop multiple income streams so you can make money without doing consulting.  We have our developer products (ARGen and Shorts are our big ones) and without any work on my part we sold some last week.  We also have our Xojo Training videos that are income.

Having that one big all consuming project.  A lot of Xojo consultants I’ve known over the years have that one big client that consumes nearly 100% of their time.  We have multiple Xojo developers and while we can do big projects that involve all team members, it’s pretty rare.  This means that our income (and risk of losing it) are spread across multiple projects/clients.  For us, projects come and go, and that means there are times when one or two of us get to work on internal projects but our income levels stay consistent.

It’s all on you.  Solo consulting stinks because it’s all on you.  I can’t tell you how many solo Xojo consultants I’ve seen come and go in my fifteen years.  Doing it all by yourself is tough and sort of ties into the one, big, all consuming project from above.  You only have so many hours in the week to code and if you don’t have help you still have to take time out for marketing, sales, and developing multiple income streams.  It’s just not possible for solo developers to be spread that thin.

Do you have a job, or do you have a business?  Over the years I’ve had multiple solo consultants chastise me and tell me that I’m just ‘training my competitors’ with my multiple employees.  Sure, that’s always a possibility, but is it probable?  So far, they haven’t and my thinking is that if they really wanted to have their own business they’d probably already be doing it without my training anyway.  Having and running a business is not the same thing as having a job.  Plus, that type of thinking comes from fear and I’m confident enough in my own abilities and experience that it simply isn’t a concern.

Consulting rates are too low.  I’ve talked about this multiple times but too often someone new to consulting will take their last real-world salary and figure out their rate from that.  This is absolutely the worst thing to do because as a consultant you don’t have a job you have a business.  You need to have a rate high enough to pay for health insurance, retirement plans, and to pay yourself during your vacation escapes each year.  It is your responsibility, as a business owner, to calculate what rate that is for you.  If you want to know my rate send me an email and I’ll gladly tell you but I will also say that if I was still a solo developer it would be higher because I can only code so many hours in the week.

You must recharge your batteries every now and then.  Without that you become inefficient and run the risk of burning out and you’ll be sending an unhappy client to me to take care of their project.  Don’t laugh because some of my best long-term clients came from a solo Xojo developer that had to leave consulting for one reason or another.  Some left because they were charging too little to pay for health insurance, retirement, and to recharge their batteries on a consistent basis.

So what do you do to recharge your battery?  And why do you think many people fail as solo developers?