RAD Still Means You Have to Learn the Language

Xojo is a great development tool that is a Rapid Application Development (RAD) environment.  That’s marketing speak for you can get stuff done quickly.  The marketing speak isn’t wrong but for many people they think this means that Xojo is ‘easy’ and the learning curve is next to nothing.  I hate to break it to those developers, but it just isn’t true.  Xojo, like any development language has a learning curve.  It might be a lot less than others but there is definitely one.

The truth is that Xojo is RAD once you learn how it works.  This means you have to learn the basics of the IDE, the language, and the debugger.  And only after understanding the basics of Xojo can you start taking advantage of the RAD part.

There are parts of Xojo that aren’t so RAD.  One of those, in my opinion, is database coding.  You still need to know SQL, and use the basic database classes to read and write data into your application.  In fact, it’s so low level that the IDE does not help you, in any way, which may lead to database errors.  The IDE will happily let you try to put a string into a numeric field in the database.  What worse is that depending upon which database is used (looking at you, SQLite) it won’t complain when you do so (thankfully this is not true of all databases).

Putting data into a database using the database classes is a two step process.  One, you have to query the database knowing what the field names and datatypes are as there is no autocomplete for them.  Xojo will happily let you (try at least) put a date value into an integer at design time.  It’s not until you try all this at runtime that things fall apart.  The same is true for updating and inserting data.  These are the reasons why we came up with ActiveRecord – our database classes for Xojo.

ActiveRecord is our way of making the Xojo compiler a little bit smarter.  It maps each table to a class and the properties in that class map to the database fields.  ActiveRecord checks to make sure that all of the fields in the table are represented in the class.  If not it flags the developer.  (It does way more but this post isn’t really about ActiveRecord.)

From our experience, jumping straight into ActiveRecord isn’t all that helpful for new Xojo users.  It’s a shortcut and you’re depending on our code without understanding it and I strongly discourage it until you’ve gone through the pain and tedium of using the standard Xojo classes.  In fact, when we train new developers we ALWAYS have them do a small project using the standard Xojo database classes.

Then we train them in how to use ActiveRecord.  The setup is a bit more involved and it’s not a perfect system, but once they start using the Table/Field autocomplete and having the compiler warn about mismatched datatypes they start to understand how much faster they can code database applications.  We are consultants, after all, and time is money.

Rapid Application Development systems do NOT mean quick to learn and being able to create an application with no experience.  RAD means that AFTER you’ve learned how it works it can be incredibly fast.  Once you learn Xojo is *can* be very fast to develop applications.

Anyone disagree with this?  What is the best method of learning Xojo?  Online documents?  Webinars?  Videos?

What is the Best Font for the Xojo Code Editor?

Somehow, after working with Xojo for seventeen years I’ve never changed the default typeface for the Code Editor.  It’s not that big a deal, really, but there are times when the default proportional font causes some issues.  At times it’s hard to read the difference between i’s, l’s, and 1’s as they all tend to blur together.  There are also some issues with selection and cursor placement that are annoying.

If I can find the right font I’ll change in a heartbeat.  What do you use and why?

Xojo 64-Bit Debugging

We’ve migrated a couple of projects to 64-bit and for the most part I’m pleased with how Xojo handles it.  It’s pretty seamless and it just works.  I can’t ask for anything more.  Additional observations:

The lack of Windows 64-bit debugging makes life difficult.  This appears to be corrected in 2018 R1 (in beta now) so that will be a most welcome change from having to go old-school and use logging to debug my Windows applications.  64-bit debugging in macOS and Linux works just like 32-bit applications.

There is no incremental compiling, yet, in Xojo.  This makes the debug cycle much longer than we’re used to with 32-bit applications.  When you debug a macOS or Linux application the dialog is quite clear that incremental compiling is off so there’s hope that the next step in this process is to get incremental compiling working.

The 2018 R1 beta cycle has taken a long time.  Presumably the level of effort to get the LLVM compiler working for Windows 64-bit debugging was painful.  And now that it appears to be solved hopefully all the other goodies on the plate (interops, Android, web 2.0) can all proceed at a good pace.

I had an instance the other day in 2017 R3 where Target64bit didn’t work.  After struggling with it for a while (because it should have worked) I deleted the plugin cache and restarted Xojo and voila!  It started working again.  I wish I had a better way of diagnosing stuff like this.

Miscellaneous:

I’m a big fan of the Einhugur Treeview control for several reasons.  First, it’s very fast with the ability to LockDrawing.  Second, since nodes are persistent you don’t have to go to extra lengths to manage your nodes as the user expands and collapses nodes.  Load them once and they’re there for the duration.  It’s a good option, in my opinion, for really fast development work.

The only drawback I have with the TreeView control is that it’s not compatible with Gtk3 yet.  According to Bjorn it won’t be until this summer.  This means any Linux projects using it will have to stick with Xojo 2017 R1.1 until it’s updated.

Happy Coding!

Updates

One of my goals for 2018 is to write more.  So here’s an update on stuff.

We hired a new developer who comes on board in a few weeks.  I’m really excited about his Xojo experience and what he brings to the company.

The planets and stars aligned and I will be going to XDC in Denver next month.  This makes me very happy as XDC is one of my favorite events!  I get to immerse myself in Xojo for a week and see all my friends and meet new ones.  I’m not presenting so that makes life a little easier too.

The week of XDC is going to be hectic as the weekend before as the FRC robotics team my son is on will be attending the World Championships in Houston.  Last weekend they won the Heartland Regional Tournament in Kansas City.  After a pretty disastrous first day where a lot of mechanical issues arose they had a solid last day, got picked by the 3rd seeded alliance, and eventually won the tournament (an alliance is composed of three teams) and advanced, automatically, to the championship tournament in Houston.

If you are geeky and interested in what these kids build, here is the final match where they won the tournament.  https://www.thebluealliance.com/match/2018mokc2_f1m2

Serial Devices as Keyboards – Yuck!

We’ve recently had a number of projects that required the use of a serial devices in desktop applications.  In all cases the clients said the devices are, “easy to use,”  since they act just like a keyboard.  If our experience is typical then I’d hazard a guess that many Xojo developers are frustrated with them.

Several projects required the use of barcode scanner.  Having a barcode scanner work as a keyboard makes sense, I guess.  It means that it can work with literally any application, anywhere, any time.  All it needs is focus on a text field and whatever the scanner sees it puts into the control.

In another project we had an ultrasonic sensor that would take the application out of idle mode and present the user with purchasing information.  Again, it acted just like a keyboard which means it works with any application as long as you had focus in a text field.

If you happen to know WHEN this information is going to come in it’s not so bad as you can plan for it.  Putting the focus in a field and waiting for information is easy.  It’s not so easy when that information could come at any time.  Of course all of our applications had data that could come in at any time and we had to be prepared to act on it immediately.

If you rely on a TextField or TextArea getting this information the rest of your interface can really suffer.  It means that when your barcode/sensor field loses focus you have to get it back (or you lose information).  Do you do this right away or wait a few seconds?  And if you have a complex user interface how do you deal with tabbing between controls, or even simple things like a user changing a checkbox because the focus is lost on your TextField?  It can be a nightmare to try and figure out and get right.  The differences between Mac and Windows and Linux can be frustrating!

The answer that we ended up implementing was putting the barcode readers into serial mode.  I’ve not run into a barcode scanner yet that couldn’t be used in serial mode.  Every scanner has a gazillion different modes and properties (all set via barcode of course) and one of them is to make it appear as a serial device to the computer.  On Windows this is a COM port and on the Macintosh they tend to show up as a USB Modem.  If I had to guess I’d say it’s harder getting barcode readers that are Mac and Linux compatible.

Once it’s in serial mode it’s almost trivial to create a class that monitors the serial port and reads the data WITHOUT needing the focus in a TextField.  The class then distributes the data to the objects that can consume the data.  What I do is have the window or objects register itself with the class and then when the data comes in the class sends it to all registered objects.  Each of the objects has an Interface with a simple HandleBarcode method.  This is known as the Observer Pattern and there’s an example that ships with Xojo.

My ultrasonic sensor wasn’t so easy to overcome as it couldn’t be put into serial mode.  However, it did come with a Windows-only SDK (thankfully it was a Windows only project) and with a little help with Declares we were able to get it working so we could tell if someone had walked up to the device and when they had walked away.  I’m not sure what we would have done if it had been a Mac or Linux project.

Serial Devices are relatively easy to work with in Xojo (as long as they show up in the serial list).  Having to deal with devices that act as keyboards not so much.  I’d highly recommend trying to get them to work as serial devices and save yourself a ton of grief.

What’s been your experience with serial devices in Xojo?