AutoComplete Wish

I understand that the future of Xojo is API 2.0.  I have used API 2.0 and while I disagree with some of the naming conventions I can live with it.  I do have a problem with many of my older projects, however.  My older projects, especially the big ones, will most likely never use API 2.0 because it’s simply too big of a task to convert.

To upgrade to API 2.0 for a desktop project I have to change my error handling to go from checking for error codes to handling exceptions.  Any string manipulation cannot simply be upgraded because the older API is 1-based and the newer one is 0-based.  And the sheer number of property name changes is disastrous in some projects.  Converting from Date to DateTime is not a simple replacement either.

That’s not to say that these things are not doable but they are not desirable right now.  And I’d really like to not accidentally invoke an API 2.0 method or property because AutoComplete shows me both.  AutoComplete conveniently shows me the old, classic property/method in red which is great but I have no way of knowing what is new for API 2.0.  Therefor I’d love to have the option to choose what is shown in AutoComplete.

Feedback 57885 Feedback #57885 is just that.  This case is currently ranked fairly high so I’m not the only one that thinks this is a great idea.  The basic gist of it is this:  there is a preference setting that allows me to select what I see in AutoComplete, API 2.0, API 2.0 and Classic, or just Classic API.

In the ideal world (as stated in the Feedback case) this would change the deprecation warnings for API 2.0 if you’ve selected Classic API and it would also switch the local documentation to the proper usage to avoid confusion.

Obviously, Xojo does NOT want to implement this because API 2.0 is the future of the platform.  My argument is that without this mechanism many of us with older, big projects, won’t update our licenses because we can’t/won’t use Xojo with API 2.0.  

This is not a good situation to be in because I feel we’re one macOS upgrade away from disaster.  If you’ll recall before Catalina was released FolderItems were broken in  for a while.  This turned out to be an Apple bug that was fixed.  Another example is the ColorPicker and if you’re using an older version of Xojo you have issues with it that you have to workaround.  What happens with Son of Catalina comes out and something else is deprecated and we *have to* upgrade to newer Xojo.

You might feel like I’m complaining for the sake of complaining.  I assure you I am just looking out for my clients assets and my own hard work.  I can’t justify the cost and expense to upgrade to API 2.0 and I really don’t want to mix and match API’s.  I could use a newer version of Xojo but I just can’t take the chance of using something (API 2.0) that’s not fully proven (to me) yet.  All it takes is one mistake and I have a mad client.

Currently 57885 is ranked 9th.  If you’d like to see it get implement throw your points at it.  What do you think?  Am I agonizing over AutoComplete too much or do you think I’m justified in my concern and request?

Xojo Web 2.0 with New API 2.0 Event Names

Xojo is usually pretty tight-lipped about future releases with good reason.  We, as users, usually hold them to features that they mention (even when they throw out the usual disclaimers about things might change) so it’s pretty unusual for them to offer any information on future releases.  In the past month or so there has been information leaking out through the forum that says that Web 2.0 is in the later stages of development and they are pretty confident on the feature set.

We already know that Web 2.0 is using API 2.0.  One thing we did not know until recently is that Web 2.0 is going to use the ill-fated new event names that so upset the community in the 2019 R2 release.  We don’t know exactly what the events are going to be in Web 2.0 but we can safely assume the standard Open and Close events are now going to be Opening and Closing.  I (naturally) have several thoughts about this.

First, I think the event name changes are needless.  Opening is not more clear than Open.  Closing is not more clear than Close.  I think the new names are as meaningless as the originals.  So I think using the new events names is a complete waste of time.  Instead of the twenty plus years of institutional memory we all have with event names, not to mention documentation and example code we have to learn new event names.

It won’t matter for Web 2.0.  Probably.  I say probably because we don’t know for sure but the hint is that ALL of the Web 2.0 classes and controls will have new names and thus not affect the 3rd party market as much (although we can presume that anyone selling 3rd party controls for Xojo web has a big task in front of them updating them for Web 2.0).  Does this class name change extend to WebApplication and WebSession too?  Only time will tell.

Another reason why it might not matter is that subclassing controls in Xojo web apps was hard.  Maybe non-existent?  Regardless in our really big web projects we NEVER subclassed web controls.

If indeed every control in Web 2.0 is using a new name it eliminates much of the griping that we had with Xojo 2019 R2 because there is no existing market.  It’s all new there are no naming conflicts.

Since events are added via dialog in the IDE most users will probably just roll with the changes.  Since converting any Web project is a one-way process most users project won’t notice it.  There’s still the possibility of Raising a non-existent event I suppose but I suspect that’s a more advanced feature many Xojo users don’t use and presumably the compiler will give a useful error message.

If the new event names are indeed the future it makes zero sense to have part of the product use Open and another part using Opening.  So this means there are going to be new controls (presumably for desktop and mobile at some point) that have new unique names and therefore use the new event names.  Again, same situation since if they have new control/class names there is no issue with conflicts.  This is similar to moving from the old HTTPSocket to URLConnection with similar functionality but slightly different events.

This last point is the most important one.  If Xojo hadn’t foisted the new events names in the old classes to begin with we wouldn’t be where we are at today.  I still think the new event names offer zero clarity from the old names, but whatever.  I’m just a user, don’t work for the company, and I’m not an MVP so my opinion doesn’t matter.

Okay, Xojo users.  What are your thoughts on using the new event names in Web 2.0?

One last random thought:  Because Web 2.0 sessions have been added at the Xojo Developer Conference (a.k.a. Xojo.Connect) I’m guessing that it will be released as a beta during the conference to attendees.  I am not planning on attending so you’ll have to get your news elsewhere.  This will be the first conference I’ve not attended since 2004 or so.  Hope everyone has fun and gets a lot of useful information out of it.

Xojo 2019 Release 3.1

Last week Xojo 2019 Release 3.1 hit the internet.  This small bug fix release is a critical update and is recommended if you are using one of several areas.  Let’s get into the details.

One of my biggest issues of concern with API 2.0 is with a dangerous memory leak in the DatabaseRow class.  Doing practically anything with a database would quickly eat of RAM until it brought your machine to its knees.  R3.1 fixes this issue and also a memory leak when using ODBC.

A couple of iOS bug were fixed in this release.  R3.1 fixes a regression that caused iOSTextAreas to overflow their bounds when the border was set to None or Regular.  iOSView headers no longer show the previous view during the PushTo animation.  Xojo added the Operator_Compare to the ColorGroup so that it can be compared against a color value.

A number of API 2.0 bugs (besides the database bugs noted above were fixed):

  • TextArea.SelectionAlignment now accepts enum values.
  • String.IndexOf now properly matches its signature when you leave off the startPosition but include ComparisonOptions or Locale.
  • If an empty name is used in the TimeZone constructor it will create an instance for the current timezone.
  • String.LastField now works
  • SerialConnection.Connect no longer raises an Error event.  It now throws an exception as expected.
  • DateTime no longer reports a Nil TimeZone

In Windows, having multiple HTMLViewers on a window (or multiple windows) no longer continuously switches focus.

In MacOS setting FolderItem.Visible no longer inverts the visibility.

The Plugin SDK now lets you access the new API 2.0 string extension methods.

The burning question that everyone wants to know:  Do I think that Release 3.1 is safe to use?  The answer is a definite maybe.  Let me explain.

I’m still not sold on API 2.0 being completely stable.  A few additional bug reports were filed after R3.1 was released including a GenerateJSON bug with Variant arrays (Feedback 58940), and a DatabaseColumn.Value bug where value always returns a String value (Feedback 58934) where it should be bringing back the correct data type.  Both of these bugs are marked as fixed and ready for 2020 R1.  Unfortunately we don’t know when R1 will drop but if I was a betting person I’d guess sometime in March either the week of Xojo.Connect or maybe even later.

If you’re using Classic API then I believe R3.1 is safe(ish).  I’ve experienced some oddities in the Constants Editor but I can’t replicate an issue where it reverts the value with no intervention on my part.  The new ColorGroup Editor for iOS projects just seems sluggish but that may just be the result of the new ColorPicker.  If you’re doing iOS projects you pretty much have to use R3.1 to stay up to date.

I have migrated a few projects to R3.1.  A few that I’ve attempted have had compilation issues and I haven’t gone back to determine if they were plugin or code issues and frankly I’m not that big of a hurry to upgrade.  R1.1 is still working fine for me and I don’t need the hassles involved with major Xojo upgrades.

So my advice is to test the heck out of your projects if you upgrade to R3.1.  I say this every release (because its true) but if you’re using API 2.0 then massive testing is a necessity. I put it this way: do you want to bet your company and/or product on trusting a new API?

What is your experience with 2019 R3.1?  Is it worthy?  Are you holding back and, if so, why?

Xojo MVP’s

Xojo announced today the creation of the Most Valuable Professionals (MVPs) advisory board. More information here: https://www.xojo.com/mvp/

Having ‘known’ these five Xojo developers for many years (mostly online and a few in person) I think they are an excellent group to advise Xojo. Most of these developers have many years of Xojo experience ranging from being 3rd party control and library developers to consultants to commercial application developers.

It makes me happy that every single one of the developers on the Advisory Board is what I would call part of the ‘professional’ developers of Xojo. It is surprising, however, that there are no ‘citizen’ developers on the board. So I call this a mixed signal to who Xojo is trying to appeal to (obviously it’s everybody but I think you get my point).

The Association of REALbasic Professionals (ARBP) tried to do this ten years ago with no success. The groups mission was to help inform Xojo (then Real Software) on what the professionals wanted out of the tool. If I recall correctly the only thing that was ever implemented out of our top 5 list was reporting. Grids, PDF support, and more basic controls never materialized. Sadly, we all still want those options.

It’s not being said but I believe the MVPs Advisory Board is a direct response to the virulently negative (and vocal) reaction by some Xojo developers had with the rollout of API 2.0. I am one of those developers and it is no big surprise that I was not invited to be on this board and, if I’m being honest, I’m not sure I would have accepted anyway.

We don’t know how the advisory board works, or even if it will significantly change how Xojo approaches future changes. Even if they do have significant input I’m not sure we’d know unless Xojo specifically tells us.

Good luck to this group and Xojo: There are some relationships to mend.

What are your thoughts about the MVP’s?

Databases and Xojo API 2.0 And Why I’m not Using it Yet

Now that API 2.0 is more or less been through two releases (2019 R2.1 and 2019 R3) many Xojo developers are starting to poke around with API 2.0 in their database applications.  There are many things to like about the changes to the database classes and our own ActiveRecord class does many of these things.  Things like throwing exceptions when there are errors definitely get your attention whereas in API 1.0 unless you check for the error you may not know anything bad happened.  The built-in Prepared Statements are a super nice change too.

Despite all the good things with the db classes in API 2.0 I recommend holding off until one, very important bug, is fixed.  Feedback case 58739 is such a huge risk that you simply cannot use the new API 2.0 classes in your Xojo projects yet.

The essential detail of that case is that Xojo is not releasing objects as it should.  Norman did a test case and showed that when using API 1.0 his test project had 24 objects at the end of the test run.  Doing the same thing in API 2.0 had over 43 million still unreleased objects!  This means there is a huge use of memory in the application and in 32-bit applications it will simply crash once it consumes 4 GB of RAM.  64-bit applications will last longer but still bring your computer to its proverbial knees.  

The Feedback case talks about SQLite and in-memory databases but other reports are that it’s in other databases as well including ODBC and MS SQL Server (case 57978).  The good news is that 58739 is marked as fixed as of January 7th, 2020 (57978 has not been updated).  But unless Xojo issues a point release to 2019 R3 we won’t see this fix until 2020 R1 is released and there is zero evidence of that happening any time soon.

Several people have contacted us about an updated ARGen that generates API 2.0 code.  We are holding off until we feel API 2.0 is rock solid.  So until this is fixed we are not using or advocating for API 2.0.

Have you found anything else in API 2.0 that should discourage Xojo developers from using it?

Xojo 2019 Release 2.1

Xojo 2019 Release 2.1 hit the web today.  If you are using R2 and any of API 2.0 this dot release is a must for you.  I almost would have almost preferred this release to be called R3.  The biggest change in Release 2.1 is that the API 2.0 events have been dropped from API 2.0 entirely.  There are also quite a few other changes and bug fixes that might impact your projects too.

Removal of the API 2.0 events was a concession to the 3rd party Xojo market (myself included).  There really was just no tenable way for Xojo developers to support both the old and new events simultaneously and after much lobbying and teeth gnashing they were removed.  

If you had implemented the new Events the R2.1 IDE will rename them back to the old events.  This is a good feature, but I’m always leery of the IDE changing code on me without my knowledge.  I recommend making a backup of your project before using this release.

Not everything is perfect with API 2.0 as it’s still hard to provide backwards compatibility with versions of Xojo prior to R2.1.  All of the new API 2.0 Properties and class Methods are significantly different and permanently change your source code that is not compatible with pre-API 2.0 versions of Xojo.  To help with this Xojo has added a new compatibility flag under the Gear icon in the Inspector that works with classes and properties.  You can check if the Object, Method, or Property is API 1 or API 2 compatible.

Really, these flags should be titled XojoVersion < 2019.021 and XojoVersion >=2019.02.1 to make it more clear.  But in reality this means that a Xojo developer must be using Xojo 2019 R2.1 or better to take advantage of these flags.  To be honest I’m still unclear on how these flags really work and the documentation regarding them is sparse.

Another change is a new menu option called Analysis Warnings under the Project Menu.  This dialog lets you pick and choose which warnings to see when you Analyze your project.  If you set “Item X is deprecated.  You should use Item Y instead,” to false you will no longer receive the API 2.0 deprecation warnings.  This is set to false by default so you won’t receive the deprecation warning unless you go looking for it.

The FolderItem class has new methods:  CreateFolder, CopyTo, MoveTo, and Open that now raise exceptions.

Window.Controls is now Iterable and you can use them in a For Each Loop to iterate through all controls on a window.

The DateTime class now has an optional parameter that lets you specify the TimeZone.

There are ton of bug fixes.  Here are some of the highlights:

The IDE no longer crashes on macOS 10.15 (Catalina) when clicking on a color swatch in the Inspector and then navigating to another control before closing the color picker.

RemoveAllRows no longer crashes the application under certain circumstances.

The Database Editor no longer throws exceptions when dropping table columns.

They fixed a number of memory leaks.  This includes (but probably not limited to) ODBCDatabase when binding parameters to prepared statements, MSSQLServerDatabase when using Prepared statements.  When database objects go out of scope or are set to nil.

There are numerous examples of Deprecations with Replacement warnings now working properly with various classes.  Constants have been replaced with more enums and so on.  There’s just a boatload things working better with API 2.0.

In general if you are already using R2 then you MUST upgrade to R2.1.  If you’re not using R2 then I still suggest waiting for at least another cycle since more bugs will be found and probably a few more things tweaked.

If you feel like you’ve wasted your time with R2 I feel your pain.  The whole R2 cycle was really long yet API 2.0 was rushed through without much  thought about the existing Xojo community and ecosystem despite attempts at communicating this information.  I just don’t see the benefits of disrupting the entire user base, 3rd party ecosystem, not to mention 20 years of documentation, internet search engine results and so on, for what, in my opinion, are arbitrary and meaningless name changes.  Some of the name changes make little sense but that’s a different argument that I’ve made before.

Personally, I would have appreciated the approach that they took with the URLConnection class that replaced HTTPSocket.  It was a new class and you didn’t have to use it.  It is using the new style exceptions rather than relying on error codes and it is a complete break from the old class.  They did this with DateTime and RowSet and I’m fine with those.  But having FolderItem (and other classes) now doing double duty depending on *how* you create them is a long-term support disaster.

So there you go Xojo coders.  Xojo 2019 R2.1 is out and it’s better than R2 and has major changes that make our lives a little easier.  What are your thoughts about Xojo 2019 R2.1?


[Edit] Apparently the Analysis Warnings dialog is NOT new. I’ve just never noticed it and, until now, I guess I’ve never needed to care.

Customers For Life

I highly recommend you read/watch this post: https://socialtriggers.com/lose-customers-alienate-clients/

I’ve been doing consulting work for over sixteen years and a vast majority of it using Xojo. During my time with my own clients I’ve tried real hard to keep them happy because I’ve always known that happy customers come back. Finding new clients takes a lot of effort.

I know I’m not the least expensive Xojo consultant out there and I’m certainly not the most expensive either. Our billing rates reflect what we feel is a good value. If our rates are too high for a prospective client I’m okay with not getting their business because it’s not worth it to me to compromise on that (and I’ve pointed them to other developers that I believe could help them). Sometimes they come back later and sometimes they don’t.

The post I linked to talks about getting ‘Customers For Life’. I’m happy to say that we’ve had some of the same consulting clients for well over ten years. I try to make them feel appreciated and that we listen to their concerns. When things go wrong we try to make it right. Some clients have left and I hope they’re happy with the new developer they decided to use. But a lot of them stayed and that makes me very happy.

As the post said it’s not all that hard to keep a customer. All you have to show is that you have their best interests at heart. As Maya Angelou said, “People will forget what you said, people will forget what you did, but people will never forget how you made them feel.”

How does this all relate to the general theme of my blog? Well, it’s no secret that I’ve been unhappy with Xojo recently. I’ve felt for many years that Xojo doesn’t court people like me (consultants and 3rd party developers) with much fervor. I’ve generally been okay with that because the product works well for what I do for my customers and if they’re happy I’m happy.

The whole fiasco with API 2.0 has left me feeling rung out and unappreciated. Many of the beta testers gave their opinion and concerns about API 2.0 very early in the R2 beta and those concerns were either ignored or dismissed. Those concerns have since been confirmed by the 3rd party developers.

If you had asked me a year ago would I be this mad at Xojo? I’d say, not a chance. After all I’ve been their customer for a long time. I’d hate to add up all the money I’ve paid them for licenses, consulting leads, and conferences over that period not to mention the number of blog posts, the many hours to create training videos, and in general promoting their product. Obviously helping them has helped my business. I’d like to think my work has helped them too.

So what happens when they lose a customer for life? We’re going to find out, I guess. I’m not going away any time soon since I’m not going to abandon my consulting clients but rather than renewing annually like I’ve done for many years I believe I’ll wait until I’m forced to upgrade for whatever reason, or they release a version I can use.

I’ll still blog about the product because that’s what I do and I’ll continue to update our Xojo products because we use them too (converting to API 2.0 is still up in the air for now). Will I start looking at alternatives to Xojo? Yes because they’ve made me feel like I’m unimportant to them. They don’t want customers for life they only seem to want new Xojo developers.

Finding an alternative to Xojo won’t be easy. Despite its warts it’s still a pretty unique product. There are lots of alternatives that don’t do something that Xojo already does, but the flip side is that there are products that do some things way better than Xojo.

Over the upcoming months I’ll start letting you know what I’ve been looking at and why. It might be illuminating and it might just end up being that I stick with Xojo because I just don’t find an alternative (I doubt this but it’s a possibility). I’m looking at the overall package from the IDE, to the language, to the 3rd party market, to the consulting market. It’s a big task.

Could Xojo win me back? Anything’s a possibility. Heck, I want to be excited about the product again. I need it to succeed for my clients to succeed. But for now, I’m satisfied with 2019 R1 and looking for alternatives.

Ruminations on API 2.0

I took some time this week to really work with API 2.0.  I took a generic ActiveRecord project and converted it to the new API.  It wasn’t long before I found a showstopper bug with DateTime and Introspection (it has since been fixed in a beta).  There were only a thousand or so “Deprecations with Replacement” message so that was just a few hours of work.  Many were duplicates of the same bug (since I use a lot of arrays in ActiveRecord the Append method needs to change to AddRow).  Fairly easy to change if not repetitious.  No big deal, right?

Shorts, our reporting tool, has thousands of immediate ‘deprecations with replacements’ warnings.  And then I got into things like Recordset turning into RowSets and string functions changing.  After 5 hours of working on it I’m still at over 3,000 deprecation warnings.  At this point I just don’t see the point of trying to convert Shorts.  Obviously at some point I will have to but there is no immediate need to do so.

And that’s the problem with flagging all the old API warnings as Deprecations.  It’s kind of silly because there is no immediate need to do so.  It’s just an item marked as deprecated but will be around forever.  So I think it’s silly to call them deprecated in the first place.

Another issue I have with the list is that it’s not grouped in any functional way.  They appear in the list as they’re found by the compiler.  In my ideal world I’d like to work with all the Dates I’m converting to DateTime all at the same time.  Same with RecordSets to RowSets and so on.  The Check Project just doesn’t help when it has thousands and thousands of warnings in random order.

Some changes you can use global search and replace.  The caveat being that if you’ve added a similar method to your class you might kill your project accidentally (i.e. see Shorts above).  The other thing that really makes life hard is string manipulation.  In the old framework strings were 1-based.  In API 2.0 they are 0-based so if you were using String.Inst and checking for zero you now are using String.IndexOf and checking negative one.  There is simply no way you can do a global search and replace for that.  The other one that’s been biting me is the use of Recordset.IDXField that was 1-based.  The replacement is RowSet.ColumnAt is 0-based so that’s another thing you can’t just use global search and replace.

The 2019 R2 IDE added the ability to quickly create a #if block to separate pre-2019 R2 code with new API 2.0 code.  That works well but for large projects that might be a lot of work.  Too much work on any project of any reasonable size.  

In API 2.0 there are a lot of replacement properties and methods.  For the most part these are not a big deal.  However they don’t always make sense.  For example, the TextField and TextArea Text property have been changed to Value.  How does that make using TextFields and TextAreas any ‘easier’ to understand?  TextField1.Text = SomeVariable is perfectly understandable whereas TextField1.Value = SomeVariable is less understandable because now I need to know that I’m talking about a TextField or that SomeVariable is a string.  If you are enforcing your control naming conventions and variable naming conventions it’s not so bad, but still this seems like an unnecessary change.  It makes reading code LESS clear in my opinion.

Since the value type didn’t change (string in this case), I don’t see why this change happened.  I guess one could argue that it makes it more consistent with things like CheckBox.Value but I’d argue that CheckBox.State is the better ‘value’ property since a Checkbox can have three states.  Inconsistencies like that make API 2.0 harder to use in my opinion.

The new Event names in API 2.0 is a big deal.  Nearly every control event has new event names.  But then some like MouseMove, MouseDown, MouseUp didn’t change.  Seriously, if you are going to change the event names for practically everything why not go all out and change everything?  Which begs the question why were some changed and not others?  I digress.

Some changes like Button.Action changing to Button.Pressed actually make some sense.  There was actually confusion from new users on what event to implement.  I can’t tell you how many times I saw a new Xojo user implement the MouseDown event because it looked more promising than Action.

But some new event names are just stupid.  Timer.Action event is replaced with Timer.Run.  WTF was this for?  The Timer has one event and I could argue that “Run” is not an accurate description of what that event means.  The timer isn’t ‘running’, it’s finished running.  Maybe a more appropriate event name would have been “DoYourOneJobNow”.  This begs the question I’ve been saying for years that why do I have to implement the timer event at all?  Rarely have I ever used with without the event.

And sharing code between versions of Xojo is totally borked.  Say, I have a class written with API 1.0 and I implement the Open event and then give it to you.  You’re in 2019 R2, create a subclass of my control, and implement the Opening event (because that’s what you want to use because you don’t want those silly deprecation warnings).  However, when you do this you’ve now kept my Open event from being called.  Thus whatever I had in the Open event is no longer run.  To me this is the most egregious bit about API 2.0.  Me, as a 3rd party Xojo developer can’t control what you’ve implemented.

There are several solutions (probably more) to the events issue.  First, the compiler, in 2019 R2 and above must produce an error if both the old and new events are implemented.  It would require a compiler engineer to move up the chain and see if both old and new events are implemented in the object and then spit out a compiler error that is understandable.  Who on staff could do this?

Another solution is to alias the events so that if someone implements the Opening event it automatically calls the Open event.  One question that’s not answered yet is:  Do we know if API 2.0 events fire in a different order than the old API 1.0 events?

Another solution that I’m pretty sure Xojo will not do is revert the events back to pre-API 2.0 status.  This solves all of the backwards compatibility issues that the Xojo 3rd party developers have with API 2.0.  We can deal with new methods using the #if XojoVersion technique but I don’t see how anything else is going to work and keep everyone happy.  The new API 2.0 properties in pre R2 projects could be hard to deal with so I’m not sure the best way of dealing with those since any flags put in for R2 won’t work in pre-R2.

In general, I think API 2.0 is a hot mess.  You don’t HAVE to upgrade your project to API 2.0 and I highly recommend that you do NOT for the foreseeable future.  I have not migrated any existing clients to R2 and have told clients that do their own development to not upgrade as well.  The API 2.0 saga is not finished by a long shot and it will take a while resolve itself (hopefully).

I’m Not Xojo’s Target Audience. Is Anyone?

I took the time out of my schedule to reach out to Xojo this week to discuss the issues I have with API 2.0 and other topics.  It was a fruitful, if somewhat disappointing, conversation with Geoff.  Like Anthony from Graffiti Suite I am cautiously optimistic that some of the worst issues third party developers have with API 2.0 might be alleviated.  Really we won’t know until we see their solution

One of the topics that I brought up was that these issues (the new Event names and marking anything from API 1.0 Deprecated – even though they’ll be around for a many years to come) were brought up early and often in the beta program.  I said that honestly, it made us feel that our input is not valued.  Geoff’s response is that the beta testers that brought these issues up is a small subset of the overall beta program and what they (Xojo) didn’t realize was those beta testers have other Xojo developers behind them (other Xojo developers) that aren’t in the beta program.  They assumed that most of our users were using the most recent version of Xojo.

So, in other words, the biggest, most active users of their development tool, that are in the beta program because they want to be and need Xojo to work because of THEIR clients, their concerns could be ignored.  It means the professional Xojo users aren’t considered a part of their target audience.

Wow.  That is stunning to tell someone that has been in the beta program for (probably) over fifteen years that their input doesn’t matter.  The three pro licenses that I’ve been purchasing year after year for over a dozen years doesn’t matter.  The many years of blog posts promoting the product don’t matter.  The thousands of hours of streaming video training about the product don’t matter.  

I’ve been going to Xojo Developers Conference (XDC) for years.  I’ve spoken at all of them since 2004.  The conferences are expensive enough to attend that really it’s only the professional users that attend.  There are some citizen developers that attend but mostly it is people that make a living off of using Xojo in some way.  Maybe this is why XDC is now being marketed as Xojo.Connect? Targeted for citizen developers?  I don’t know but it’s not any less expensive.

I asked Geoff if they’ve ever asked why long-term users stopped renewing.  The answer was no.  They did it years ago with people that signed up to download Xojo but never purchased.  They couldn’t find a pattern which I totally get.  Heck, I’ve downloaded and discarded dozens of development tools over the years just to kick their tires.  But not knowing why someone stopped paying you $700 year after year?  Seems like it would be an important thing to know.

I’ve been around a long time and have remained friends with some of those former Xojo developers.  Some leave because of long-term bugs.  It is disheartening to report a bug that affects your app that gets ignored for years on end.  Granted not all bugs are equal but a show-stopper bug is just that.  When your bug is ignored it’s pretty easy to check out.

Some leave because Xojo isn’t as RAD (Rapid Application Development) as it is billed as.  Database driven applications (which I would say is what most businesses need) is pretty bad (hence why we’ve had our own library forever).  Why use Xojo if it’s not RAD?  

Some leave because there is a lack of capabilities in the product.  iOS (but also true for all targets) is painfully lacking in capabilities that force you into learning complex declares.  There are no built-in controls for Date, Time, Timestamp, or numbers only Text Fields, exporting to PDF, no ability for applications to have a report editor, a good grid, etc.  Some of this is because Xojo is the lowest common denominator between Mac, Windows, and Linux (for desktop) and doing these things cross-platform is really hard.  

Some leave because of the lack of options.  Xojo has a tiny 3rd party add-on market.  You only have a few options (if any) for some things or you make them yourself.  Users hate reinventing the wheel.  Xojo itself doesn’t do much to promote or help the 3rd party market.  Other development tools have significantly more options to choose from.

Regardless, there are probably a ton of reasons why people leave.  I suspect that most come down to some variation of the above.  These are also the same reasons why new users will walk away too.

Citizen developers can walk away from Xojo with hardly a second thought.  They’ve invested practically nothing in the tool.  When you’ve been in the Xojo ecosystem for many years apparently we’re taken for granted because the cost of moving is so high.  But who are the cheerleaders for the product?  Who helps new users in the forums?  The less active the community the harder it’s going to be to get those new citizen developer sales.  I see this as a negative feedback loop.

I’ve been a Xojo consultant for over over sixteen years.  I guess I’m not their target audience.  Is anyone?

I’m Tired

I’ve not been blogging very much lately.  This summer was very busy with a lot of traveling including a trip to France to join my son who was studying in Lyon.  We camped at several music festivals in Michigan and Kansas.  In August I started coaching a rookie FIRST FTC robotics team and that’s been challenging. (They are smart kids!).  Work-wise we’ve been pretty busy with a big consulting project that’s starting to wind down.

All of that aside, I’m just not excited about Xojo at the present time.  2019 R2 was a very good release until they added API 2.0 into it.  I can’t talk about beta program specifics, so I’ll leave it at that since it has a ton of IDE bug fixes and enhancements.  I was doing active development with the R2 alphas it was that good.

Unfortunately API 2.0 was added and despite months worth of beta testing and dozens of builds, it feels half-baked, buggy, and not ready for prime time.  It feels like it could have used another couple of months to gestate and be fully thought out before it was released to the masses.

The new events don’t really solve much of anything and in most cases just make life incredibly difficult for existing Xojo developers.  If the goal was clarity I’m not sure that going from Open to Opening, to name one case, really solves anything.  If anything, I could argue that Preparing or PreparingToOpen is more appropriate for what it really means.  To be sure, I’m arguing semantics but the semantics of an API are important.

The new events make it practically impossible to use R2 and still use older versions of Xojo.  I’m already getting support questions on when are we going to support API 2.0 for ARGen and Shorts.  The answer is I don’t know because it’s non-trivial to update their code bases to API 2.0 and still support API 1.0.  I feel like I’m caught between a rock and a hard place and I know I’m not the only 3rd party Xojo developer caught in this bind.

I also think that’s part of my problem.  I feel like Xojo has willfully ignored professional developers in favor of citizen developers.  API 2.0 does nothing for me and with the way events were changed (it seems like change for the sake of change), it actually harms my business.  

The upcoming Android platform does nothing for my business.  Sure, it’s a shiny new target and I’d love to kick the tires on it, but iOS is still using the now deprecated Xojo framework.  I know the goal is to have a single mobile project and have different build targets (like desktop does right now) but at this point I have no idea when that will happen.  Based on what was reported at the MBS conference last week, there is still significant work to be done on Android yet.  Then we still have to wait on an iOS update to get it to API 2.0.  Could that even happen by the end of 2020?  I’m not so sure.  Maybe.  But what gets put on hold during that time that I could use now?

Speaking of iOS it seems to be languishing on its own.  It’s been out for years and to do some pretty common iOS tasks you have to go through declares.  That’s not exactly a RAD environment.  I’ve done a commercial project with iOS and it was great to use my favorite language, but I was literally 15 minutes away from giving up on Xojo iOS.  It was only with some Herculean help from several forum members that I was able to get THE key feature to work at all.

Raspberry Pi is another target that’s been fun to play with.  I did an electric kiln controller with it and again it took going back and forth on the forums for several weeks to finally nail down some of the problems.  To be fair I had a bad thermocouple converter, but the fact that there were only a few people using it made it that much tougher.  The Do It Yourself (DIY) and Maker movement is huge and yet Xojo is barely making a dent in it (I’m basing this on the lack of traffic in the Raspberry Pi sub forum).

What I could use today is Web 2.0.  What I could use today is a desktop grid control, and a simple built-in Date picker.  What I know others need today is built-in PDF export and viewing.  It’s almost criminal how old the RegEx and XML libraries are.  I’m sure we could list dozens of things we could use today rather than six to twelve months from now.

Xojo built its business on being a really good cross-platform environment.  I still think it’s a really good desktop development tool – I could even argue it’s still the best cross-platform development tool out there.  Adding half-baked targets with such a small development staff helps neither the targets nor the development staff because despite what the company line is (on being adequately staff), each target *does* take time away from other projects.

I feel abused at worst, or at least unappreciated by Xojo.  I’ve devoted countless hours talking about the product, trying to get people excited about it, only to feel like I’ve been ignored by the company.  If I write a good review of a release they quickly spread the news, but if I’m remotely critical of a release it’s only silence.  Look for this one to not get promoted either.

Besides this blog, I only have one other way to get their attention – I can refuse to upgrade until they listen to what I *need* to run my business.  If they don’t give me what I need I will look for alternatives and switch to that product.  There are only a handful of Xojo old-timers around – and that should speak volumes.  Xojo is a development tool that you want to love but it’s hard to be ignored and still love the product.

I’m tired of feeling ignored.  What about you?