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?

ARGen 3.0

BKeeney Software Inc. is proud to announce that ARGen, our ActiveRecord Generator utility for Xojo developers, has a new major update.  Version 3.0 includes a host of new features including the ability to generate ActiveRecord classes for Xojo iOS projects, the ability to use GUID primary keys, the option to include a database update module, include an audit trail module, and include a UI localization module.  There are also new ways to arrange your user interface layouts that can save you even more time when initially creating a project.  In addition to these major new features, ARGen fixes a number of bugs and provides more enhancements.

ARGen has versions for macOS and Windows.  It costs $99.95 but can be used in limited mode at no cost.  Existing version 2.x users will be provided an upgrade opportunity with a 50% discount or they contact us at support at bkeeney dot com to get an upgrade coupon.

Pricing, examples, and more details can be found at the project homepage at https://www.bkeeney.com/allproducts/argen/

3.0 Release Notes:

New:

* iOS ActiveRecord!

* Reorder fields in the order they should be displayed. This would work both on List and Edit forms.

* Name labels for generated UI elements

* Switch between horizontal and vertical alignment for UI fields and labels

* Projects can now have individual Namespaces

* GUID support (except for ODBC connections)

* Can now include a Database Update module

* Can now include an Audit Trail module

* Can now include a Localization module

* Warnings for aggregates that conflict with Xojo (note below)

* New database connection window

* New app icon

 

Removed:

* Oracle databases are no longer supported

 

Fixed:

* Add / Edit dialog now shows in web version (#3556)

* Icon now displays properly in alerts (#3474)

* PostgreSQL Views now working

* Control init on add and edit windows

* Preferences now correctly handles prefix and suffix settings

* Selecting suffix no longer causes a compile error

* Confirmation dialogs are now set up properly (#3643)

* MenuBarVisible is no longer false on any template windows (#3475)

* Rescan Schema works again

 

Changed:

* Database specific PreparedStatements

* Instances of MsgBox replaced with MessageBox (#3474)

* Enhanced Save() on add and edit windows

* Listbox.Open() now has a ColumnWidths placeholder for convinience

* Desktop projects now created with HiDPI on

* Desktop projects now default to 64 bit for Mac

* Opening a SQLite project automatically attempts to connect (#3596)

* Auto-Generate UI step is now easier to understand

Aggregates Note:

When using aggregate like Count(), Max(), Min() some DBs will return the aggregate as the field name.

Added code to warn on open project that there is invalid for xojo field names, and fail generate. 

Chrono-Optimism

At the XDC Keynote a few weeks ago Geoff Perlman said they’d no longer give target dates for new features.  Instead they’re going to say what’s a ‘priority’ and what’s ‘important’.  Software projects are often big and complex and it’s very hard to estimate the amount of work involved with a new feature.  “Happiness is all about having expectations met,” said Geoff and I think it’s fair to say that Xojo has typically been overly optimistic on when a feature is going to ship (much less when it’s going to be usable).  So instead they’re going to stop predicting when a feature will be released.

If you hear them say it’s ‘Important’, it’s something they’re seriously looking into.  It will be in the product in the not too distant future.  A ‘priority’ means it’s either in active development or will be shortly.  The Rapid Release Model is still in play which means we will still get releases three or four times a year.

In one sense I’m disappointed that they’re not going to give us any timeframe for new features.  I really want to know when Web 2.0 is going to ready for testing as we have a number of projects in development or about ready to start development that it would be really nice to know if it’s a 90 day, 120 day, or longer window.  Android is a nice to have feature, but since I’m not doing much mobile development it’s not that important to us, but I can see how for some it is a huge need.

In another sense I understand why they’re not going to give us target dates any more.  They’ve missed every projected release date that I can think of and I’m going back a lot of years.  It was about a year ago this week, in Berlin, that Geoff said that Android would be out by the end of 2017 when the reality is that we’ll be lucky if we see it by the end of 2018 (that’s just a guess on my part and having having been around a long time).  I would love to be wrong on that guess but it’s a new target that involves a ton of compiler, framework, and IDE work not to mention the need for Interops (a dependency) to work well.

Estimating a project is not a science.  You’re asking software developers to take a wild guess at how long a big feature is going to take.  When you make that initial guess you don’t know that replacing this small piece of code will affect this much larger piece of code over here.  Or cause this other piece to not work right thus forcing you to redo that other piece too.

In some respects creating a new project is considerably easier than replacing code.  In new projects you’re touching everything anyway but subconsciously you’re holding most, if not all, of the work in your mind and you shape it as you go.  Big, existing projects, or OPC (Other Peoples Code) projects, are considerably harder since not only do you have to read the code but also figure out the intent of the code and second guess what the original developer was attempting – not always an easy task.  I’ve never seen the code for the IDE but I’d imagine dozens of people have worked on it over the years with varying degrees of competency and coding styles.  So whatever work you do you have to read, interpret, change, and test to make sure it doesn’t break something somewhere else.  Tack on multiple environments and targets and it’s a herculean task.

I’ve spent the last four years working with my son’s FRC robotics team (team 1982) as the programming mentor.  They have six weeks to design and build a robot to a very demanding set of specifications before they crate it for competition.  These 120 pound robots are relatively complex and I’ve seen it time and time again where the kids have ‘Chrono-Optimism’ in what they believe they can get done in after-school meetings (some with mentors present and some without) and on Saturdays.  Granted, they spend a LOT of time working on the robot, but they’re just kids and most of them have never done anything like this before.  They don’t know what they don’t know and most years they’re scrambling just to get a working robot.

This year, the group of seniors really thought about what they wanted to do.  They knew it would be challenging, but they decided to change their build process and use a more modular hardware design which meant new gear boxes, wheels, framing, etc.  They also decided to build two robots which, for a team that’s never done that before, was …ambitious.  Then they decided that they wanted to go two regional tournaments.  Again, ambitious for a team that’s never done that.  From previous years they also learned something else:  they were attempting to design too much on the robot.  If there were three major tasks that a robot had to accomplish they couldn’t do all three with the resources and experience they had.  They couldn’t change the amount of time to build the robot so they changed the one thing they could – the scope of work – and made the robot simple and sturdy.

The Universe works in mysterious ways and has ways of throwing a monkey wrench into the best of plans.  The last day of build season this year happened to be a day off so the plan was to have a twelve hour work day to finish the robot and test.  Instead, Kansas City had a snow storm which cancelled all school activities.  The robot was not mechanically complete and not functional programming-wise.  The kids were devastated.  But there is a silver lining to their story.

The robot was crated away and couldn’t be worked on for weeks, but the second robot allowed them to work on the programming and driver training.  The modular design allowed them to plan the work they needed to do at the tournament before it started.  The simplicity of the robot meant that the work could actually get done in a short amount of time before taking to the field.

To conclude this story (because I’m bragging now), the team won their first tournament which qualified them for World Championships.  They were the eight seed alliance captain in their second tournament.  At the world championships, they finished 42nd of 67 teams, but were picked as part of the 6th seed alliance.  They won in the quarter finals and ended up getting to the semi-finals where they were defeated by the alliance that went on to be third in the overall tournament (out of 400 teams).  All because they examined their past behavior and decided to change it.  They knew they were bad at estimating and changed their expectations.

I will give credit to Xojo for realizing that, like most of us, they are Chrono-Optimistic in their estimates, and decided to change how they communicate to their customers.  As Geoff said, part of their job is setting expectations and they’ve been really bad at it.  It’s clear that they said ‘estimate’ and we heard it as a ‘promise’ which is partially on us.  So now we have what’s a ‘Priority’ and what’s ‘Important’.  I don’t know if this will help them, or us, in the long run but it will be different and I’m willing to play along for now.

What do you think about this change?  Negative, positive, or neutral about it?