2018 Was a Weird Year

I hope everyone’s holiday season was good.  We’re approaching the end of 2018 and I find it nice to reflect on what’s happened and what we’ve accomplished this year.

Looking Back

Let’s start off with the blog posts.  I did 41 (well now 42) blog posts in 2018.  Five were about Xojo releases.  Four were BKeeney Software product releases.  Four posts were about the Xojo Developers Conference.  The rest were a variety of Xojo related topics.

The most highly commented blog post was from June called Chasing Xojo where I lamented that Xojo, at least until that point, seemed to be a less stable when it came to Windows and Linux due to major revamping of the drawing systems on both platforms.  In Windows, Xojo doesn’t flicker as much but the struggle to get speed was a concern for all of 2018.  In Linux, the switch to GTK 3 wasn’t as smooth as we could have hoped.

The most viewed blog post was from August called Xojo 2018 Release 2 where I did my usual review of the most recent release of Xojo.  I heavily criticized Xojo for their poor documentation in that release.  I received plenty of blowback on that one.  But I think the end result is that R3 and R4 documentation was much better.

We released two new products with BKS Report Studio and BKS Tab Control.  Report Studio is our reporting utility meant for end-users for macOS and Windows and it was built using the award winning Shorts reporting classes (also a blog post).  The Tab Control is a canvas subclass that replaces, and extends, the built-in Xojo tab control in many ways and was our attempt at replaced the old CustomTabControl that many use but is unusable for HiDPI apps.

The other major release of the year was ARGen 3.0.  ARGen is our utility to create Xojo projects that creates ActiveRecord objects.  Among the many changes was the ability to generate ActiveRecord objects for iOS projects, supporting GUID primary keys, and the ability to include Audit Trail, Localization, and Database Update modules that help in many products.  We use ActiveRecord in practically every project and having the ability to generate some basic desktop and web UI is a huge time saver.

2018 sure seemed like a mixed bag for Xojo.  The Windows drawing issues took up a good chunk of the year and I think R4 was the first solid Windows release (although I still have 2 client apps that won’t remote debug in R4).  I can’t imagine the amount of effort that Xojo and the community put into getting Windows drawing fixed.

64-bit remote debugging became a reality for all targets this year.  64-bit compiling isn’t the huge gain that many in the community hoped for but then we always want more.  We just have to remember that 64-bit doesn’t necessarily mean ‘faster’.  At least the debugger works and that’s not nothing.

Dark Mode came soon after the release of Mojave.  The IDE works in Dark Mode and we were given many of the tools to implement it in our own projects.  Dark Mode only works in MacOS but some are already clamoring for it in Windows too.  It’s still to early to tell if Dark Mode is a hit on Mojave much less in xojo.

Looking Forward

What is 2019 going to bring us?  For one, we’re almost finished with a fairly significant update to Formatted Text Control and after that’s released we’ll start with an even bigger version 4 update to the venerable word processing control to bring it up to date and extend its capabilities to make it even more powerful.

We have a number of large consulting projects that have been in gestation for many months and years.  It will be nice to have a big project or two to keep us busy.

With the release of Web 2.0 I will redo all of our Xojo training videos related to web.  They’ve been outdated for a while but it’s not worth redoing the videos until Xojo releases Web 2.0.  If they release Android I’ll start on at least some intro videos for that too.  This might finally be the year that I redo the remaining Real Studio videos.  No doubt I’ll redo them just before a major IDE change.  🙂

What do I expect from Xojo?  That’s a tough question to answer since they’re so damn secretive now.  I expect Web 2.0 to show up in time for XDC (so maybe release 2?).  I think it will be pretty solid in the first release but it wouldn’t expect it to be good until the following release.

I also think that at XDC we’ll get an alpha of InterOps but not anything other than another dog and pony show for Android.  Targeting another platform is long and tedious process and involves some serious IDE work.  How much of the iOS editors can they use?  I can only guess but at first blush I say not much.

Some of Android’s success may hinge on getting iOS to use the global framework and away from the Xojo Framework.  Nothing like rewriting an entire framework while keeping backwards compatibility.  The more I think about it the more I think the iOS rework is put on hold until Android is released.  

Which leads to API 2.0 in general.  We’ve already seen some of the first new controls to use API 2.0.  URLConnection was introduced in 2018 R4 with mixed success.  I would expect more API 2.0 controls to show up.

So what do you think?  Was 2018 a successful year for Xojo?  What do you see happening in 2019?

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!

XDC 2019 Session List

The session list for the 2019 Xojo Developers Conference (XDC) was released today at https://www.xojo.com/xdc/sessions/.  Take a look at this interesting list.

I’ve been attending Xojo developer conferences for twelve plus years (don’t remember what my first XDC was – maybe 2004?).  Each one is unique and the topics are usually interesting but do tend to be repetitive from year to year at times.  The session topics for XDC 2019 seem to be more unique than past years.

Obviously Geoff will do his keynote address and talk about what they’ve done in the past year, what they’re currently working, and what’s coming up (sometime) in the future.  There is a session each for Android, Web 2.0, API 2.0, beyond Linux, everything MS Windows, and more by the Xojo staff.

What’s left is an intriguing list of sessions that will be tough to figure out what I want to attend and which ones I can wait to see recorded (assuming they’re recorded again).  I can’t remember an XDC I’ve looked forward to more.

Carol is doing a session on Database Topics for Programmers and I’m doing one called “Xojo Mistakes We All Regret Later”.  My alternative title is “Thankfully time travel doesn’t exist otherwise my future self will no doubt come back to murder me for these stupid programming mistakes I’ve done.”

If you’ve never been to an XDC I highly recommend it.  You will get to meet some of the best Xojo developers on the planet, talk Xojo non-stop for 3 (or more) days on end, talk to Xojo staff, and have fun.  Of course that last point is mostly because of the first three.  You won’t find a bigger concentration of Xojo developers on the planet!

I hope to see you all in Miami in the first week of May.  What sessions are you excited about?

What Topics Do You Want Covered?

One of the joys of doing a blog for close to eleven years is that I feel like I’ve talked about a lot of topics and people ‘know me’ fairly well.  I always get a thrill when people tell me they’ve read this blog.  That is so cool and I thank you for your valuable time!

As many of you know I do a quick review of every Xojo release.  I often do a blurbs about updates to our own products.  Occasionally I even rant about things (you should see the posts where I never hit the Publish button!).

When I had a column in Xojo Developer magazine this blog was a convenient place to discuss the ideas from the column.  But writing a reoccurring column is tough.  Keeping a blog going for eleven years seems to be even harder.  I’ve been writing fewer and fewer posts and I’d like to change that trend.

At one point I thought about taking a topic in the Xojo Forums and talking about it in-depth  here.  We’ve been busy doing consulting work so I spend far less time on the forums than I used to but it might be an interesting way to generate new posts.

So, my fellow Xojo developers, what topics would you like to see me tackle?  Topics can include my opinions on the future of Xojo, how’s the 3rd party market doing, why did we choose <x> or <y> over <z>, or anything in between.  I’ll let you be in the drivers seat for while.

Some ground rules:

  • If you’re rude to me, my staff, or Xojo staff I’ll just delete the comment, ban you, and move on.
  • Keep it simple – this is a blog and not a magazine.  Though that doesn’t mean I can’t do a multi-part blog post.
  • I reserve judgement to make more rules as I think of them.  😉

So what topics do you have?

A Xojo Existential Crisis:  When Self is Nil

A couple of Formatted Text Control users found an interesting bug in the Xojo Windows 64-bit compiler.  If the user pasted anything into the control it would hard crash the Windows application.  I spent a couple of days trying to find a workaround and was flummoxed on how to fix.  Thankfully there’s an easy workaround thanks to Team Xojo.

In the Open event of the FTC control we create a new FTCUndoManager instance.  When the user pastes something into the control we pass the existing text into the Undo Manager so it can properly save the before state and allow an undo of the paste.

Pasting text calls the SavePaste method of the FTCUndoManager class.  This is where things start to go wrong.  This method passes Self into the constructor for the FTCUndoPaste class.  Stopping the debugger in this method shows us that self is nil!  What’s odd is several other passed in class objects are nil too (even though they are not at the control level).  That self is nil is indeed a problem since FTCUndoPaste needs the reference to the UndoManager for a variety of reasons.

How can self be nil?  After all this is a method in the class.  By definition self should be non-nil.  I think this would fall under ‘compiler problem’.  I submitted a private Feedback report to Xojo (53967)  and thankfully Xojo reviewed it quickly and were intrigued enough to look into it.  It was verified and a workaround was quickly found.

William from Xojo wrote this:  

There seems to be an issue with passing byval structure parameters (for 64-bit Window build), as a workaround you can pass these byref instead, i.e. MyFunction(…, Byref firstPa as ParagraphAttributes)

So I was able to change two methods, FTCUndoManager.savePaste and FTCUndoPaste.constructor, by using byRef for each object we pass into the Undo Manager into and in the Undo Paste class.  Voila!  Problem solved.

I suspect that FTC is big enough and complex enough to manifest some edge case for the 64-bit compiler.  If you run into an issue like this try this workaround.  And don’t forget to submit a Feedback report to Xojo since the more edge cases they can find the more likely it is they can determine the cause.

Happy Coding!

Xojo 2018 R3

The latest version of Xojo hit the internet this week.  Release 3 has a number of important new features, some changes, and the usual assortment of big and small bug fixes.  So let’s get to the highlights!

The flashiest new thing in Xojo is that it natively supports macOS 10.14 Mojave.  This means that the entire IDE (as well as all of the peripheral apps like Feedback, Linqua, and the Remote Debug Stub) draws properly when the user has Dark Mode enabled in Mojave.  

Perhaps it’s my older eyes the IDE seems very ‘light’ in color in Light Mode – meaning that there’s a lot of white and grey and the contrast isn’t nearly as prominent as it was in R2 and earlier.  Where some buttons have a slight 3D effect the buttons in R3 are flat with no grey background.  Funny enough, I think the contrast of the IDE in Dark Mode is better.

2018 R2

2018 R3

As a long-time Mac user I’m not entirely sold on Dark Mode.  Some of that is change and that I’m just not used to it yet.  In some respects I feel like I’m reverting to my college PC where light text on a black screen was the norm.  I guess the more things change the more they stay the same.

A new property, SupportsDarkMode was added to the Build Properties section to build apps with Dark Mode enabled.  To help developers the application class has a new event named AppearanceChanged to let them know when the OS has switched between light and dark modes.  

Labels, TextFields, and TextAreas running on Mojave will now use the automatic system colors to get the correct appearance on light and dark modes when text is test to opaque black (0, 0, 0, 255) and backgrounds set to opaque white (255, 255, 255, 255).  In a similar fashion, FillColor, TextColor, and FrameColor now map to proper light/dark system colors.

Since there are many OS colors available than what Xojo provides natively, you might want to look at CSTrueColors by Ulrich Bogun at https://drive.google.com/open?id=1vg-sN8_7mz18zeu9XoRWZaBc8Tm-_Enb.  

Currently Xojo does NOT support Windows dark mode but is looking into it.  A Xojo blog post suggests that Microsoft has released several API’s for dark mode and another one is due in the near future.

Incremental compiling for LLVM/64-bit targets now works.  The first run can still take some time but after that it should only compile changes.  This should significantly reduce cycle times on debugging 64-bit applications.

In Windows Xojo updated the text rendering so that it matches Win32 controls.  I’m just guessing but if Xojo ever moves away from Win32 controls the text rendering will have to change to match.  

Windows is now using the native Win32 Label control.  Overall drawing seems to be significantly faster with this change.

Among the changes is one that might affect a lot of legacy projects (we have a number of these) is that drawing directly to the Graphics property is no longer allowed.  To be explicitly clear about the change this does not affect, in any way, the graphics parameters passed into a canvas or window Paint event, nor does it affect getting the Graphics object from a Picture object.  This only affects the graphics *property* on Canvas and Windows classes.  The fact that it’s continued to work for all this time says that it was definitely time to retire this ‘feature’. 

There is also a list of 79 bug fixes.  Some Windows, Mac, and Linux framework issues fixed.  A couple of changes to MySQLCommunityServer and Postgres.  SQLite was updated.

Xojo 2018 Release 3 isn’t just about Mojave dark mode.  The 64-bit incremental compiling is a most welcome feature.  The speed increases in Windows drawing is also well worth the upgrade.  As always, please test your projects fully before releasing them into the wild.

What is your favorite new feature, change, or bug fix?  Anything causing you problems?  What are your thoughts on Dark Mode and the contrast of colors in the IDE?

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 and the Rapid Release Model

If I could change one thing about Xojo what would it be?  My answer is, without a doubt, the Rapid Release Model.  Here’s why.

The idea of the Rapid Release Model isn’t a bad one.  In the not too distant past many applications had major yearly updates.  Many still do.  In fact, Xojo (when it was called Real Studio) did this with varying degrees of quality.

Some of the complaints about the yearly, monolithic, release of Xojo (back when it was Real Studio) was that it wasn’t a very stable release and it took several dot releases to get it right.  This was the impetus that led me into the Beta Program so I could test out new features before it was released.  I was tired of new features not being usable due to an obvious lack of real world testing.

In theory, the Rapid Release Model introduces smaller changes and a few new features each release.  Releases are roughly every quarter but in recent years this timeframe has not been as consistent.  I believe this change happened, in large part, to address some of the complaints of the Rapid Release Model.  One of the complaints being that the constant drive to get new features in every release gives the software a perpetual beta feeling.  I would argue that the recent changes to the Windows drawing system certainly justifies that feeling to many current Xojo developers.  

From a developer standpoint, I can only imagine the pressure on Xojo’s small development team to constantly add new features every 90 days.  It means that developers are always pushed to get things done rather then get them right the first time.  Again, I would point to the plethora of changes to the Windows drawing system that have spanned many releases as proof.

I believe that marketing is entirely behind this new-features-every-release mantra so they can get buzz about something in every release.  I get it:  for a small company they need to create as much buzz as possible.  Buzz creates some sales and renewals.  But I think the Rapid Release Model is actually hurting them with many developers who value stability over new features.

More evidence that the Rapid Release Model is hurting Xojo is their recent change of telling customers their development plans.  No longer will they tell us the target date of when a feature is released and instead they’re simply saying if it’s a ‘priority’ or ‘important’.  Prior to this, Xojo CEO Geoff Perlman said that Interops and Android would ship by the end of 2017 and not only did they not deliver, but it seems highly unlikely they’ll get it out by the end of 2018 in anything other than an alpha release (purely a guess on my part and I’d love to be wrong).  

Being poor at estimating isn’t just a Xojo problem.  Chrono-Optimism is a human condition and I believe the old adage that 80% of the work takes 20% of the time and the final 20% takes 80% of the time.  Estimating is an arcane art form and at times software development is pure magic that takes time.  Forcing releases into this 90 day window makes the problem worse by having incomplete solutions and incomplete testing.

When all is said and done, I believe Xojo would be better off ditching the Rapid Release Model and going back to monolithic releases with regular dot releases that does nothing but fix bugs.  Perhaps this means that there are only two major releases a year.  Sometimes only one.

The Rapid Release Model is not without some merit.  We currently know that every release will fix a large number of bugs and we know roughly when that release is going to come out.  Not all bugs are created equal but for many developers we can’t wait six months to a year to get a release that fixes some bugs.  So any replacement to the Rapid Release Model must take into account that Xojo developers need a regular, perhaps monthly, bug fix releases for critical and important bugs.

I think changing to a hybrid model between the monolithic release and Rapid Release Model fits the small Xojo team better.  First, it lets the new features gestate in internal testing longer before we ever see them without being rushed out the door.  Second, the regular release of bug fix builds is simply that – bug fixes – and lets the developers continue to work on the next big thing without the pressure of having to add new things in each release.

To say that the Rapid Release Model is a failure is hyperbole.  To say that the model makes the product beta quality is also a stretch.  The truth is somewhere in the middle and I think this is an important discussion for the future of Xojo and their customer base.  What do you think?

Chasing Xojo

The most important thing for developers is to have a reliable IDE.  The Xojo IDE has been stable for a couple of years and while I don’t find it as useful as the old REAL Studio IDE it doesn’t hinder me as much as it used to either.

Another vital aspect of a solid development tool is the stability of the compiled application.  This is where Xojo isn’t doing as well.  MacOS has been stable since the transition to 64-bit Cocoa was complete.  The transition for Linux and Windows has been less successful and this has to change.  If they don’t get better, many of us will be forced to look elsewhere for a new development tool.

This post is part rant and part wish list.  I want – no need – Xojo to be better than it currently is.  Part of my frustration is the plethora of older projects that are stuck on an older version of Xojo because of issues with newer versions.

Linux is a particularly difficult platform to work on: The number of distributions and slight variations ensures that there will always be some challenges to stability.  These differences make it difficult for Xojo to create builds for all distributions that work evenly.  The new GTK 3 drawing system has been less than ideal for us.

We have several cross-platform commercial applications that have macOS, Windows, and Linux targets.  When Xojo made the transition to GTK 3 it really messed up how these applications work in Linux.  Add in some 3rd party control compatibility issues and we’re stuck at Xojo 2017 R1.1 (before the GTK 3 switch occurred).

More recently, and more importantly, we’ve had a number of projects that were last built using Xojo 2016 R3 and the client recently wanted 64-bit builds for macOS.  This wasn’t a hard transition with only a few 64-bit specific changes required.  The Windows builds (still at 32-bit) in Xojo 2018 R1.1 proved to be impossible simply because the Windows drawing system has steadily changed in (what seems like) every release since 2016 R4.  

I’m not sure what the drawing system change was in 2016 R4 but drawing doesn’t work the same way as in 2016 R3.  Then there was the change to Direct2D from GDI and that had significant bugs for several releases.  The recent 2018 R1 release introduced even more significant changes to the Windows drawing system to reduce flickering.  The caveat is that drawing is much slower depending on settings and how you’ve layered your controls.

From my experience and from what I’ve gathered from the Xojo forums is that the new ‘flicker-free’ system is causing a lot of heartache among developers building for Windows.  Sure, flicker is gone but drawing is so slow as to be unusable in some cases.  Even developers that could live with the flicker are unhappy with the speed hit.

My client eventually told me to give up because he didn’t want to foot the cost of converting to a new drawing system that wasn’t causing him issues to begin with.  So, this means I’m creating macOS builds with Xojo 2018 R1.1 and Windows builds with 2016 R3 (with the code base from that era).  That is nuts and unacceptable.

I get that Xojo will always be playing catchup with changes to the target operating systems.  When Apple or Microsoft or a specific Linux distribution changes things it has to react to the change.  Hardly ever does Xojo have advance notice of the change (remember when Apple deprecated QuickTime and stopped accepting Mac App Store submissions with QuickTime just a few months later?  Or when Apple decided that iOS apps were going to be 64-bit only?)  I think that what we have in Xojo is nothing short of miraculous.

But, in regards to the drawing systems for Linux and Windows they’ve made a conscience decision to change a critical and important system.  This makes it tough to upgrade from one Xojo version to another without a great deal of work.  Clients don’t want to hear the term ‘lot of work’ because it means it will cost them.  So we’re stuck with older, and inferior, versions of Xojo.

I guess this is the price of advancement.  Any NEW projects will have the new Linux and Windows drawing system in place and we’ll think nothing of it a year from now.  But heaven help anyone trying to upgrade from an older version of Xojo to a newer one because it will cause a lot of work.

It’s probably not possible, but it would be great to have the option to use the older drawing system and have it marked as deprecated, or perhaps we even have to force the switch to use an older Graphics object.  In the not so distant past we had the switch in Windows to allow GDI or to use the slightly different GDI+.  I would really like that option in Windows (instead of the flicker free version) and for the older drawing for Linux.

I love Xojo.  What it does is nothing short of magic.  Develop on the platform of your choice and write for the other platforms.  That’s some high level wizard stuff there.  I just wish the transitions of major subsystems were planned out better beforehand, more stable when introduced, and not in need of major work to upgrade to use, or at least have a way to use the older system version for a period while still getting to use the new version of Xojo.

I can also argue that the constant cycle of adding new features and changing things every release is detrimental to the product.  Every now and then I want a release that is comprised ONLY of bug fixes.  Marketing be damned – I just want stable and reliable releases so I don’t have to juggle Xojo versions and plugins.

There are a lot of bugs that should be fixed that have been around for years.  I understand that not all bugs are created equal but some are very serious when you encounter them and are impossible to work around.  Again, having only a couple of releases every year that do nothing but clear the backlog would be awesome.

Instead, we already know we’re going to get Web 2.0, API 2.0, Interops, and Android in the near-ish future.  Those are all major NEW features.  Can we just get a few stable releases before those things are added so we don’t have to chase Xojo versions depending on bugs?

The old way of doing releases was to do one major release a year and then issue a number of ‘dot’ releases.  It usually meant that the first release of new features wasn’t a great one because of bugs but usually pretty good after the first or second update.  With the constant race for new features every release we get to chase versions based on what bugs we can and can’t live with.  

Please, Xojo, be better before I have to go in search of a new tool.

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?