In my search for Xojo alternatives I was pointed to Lazarus https://www.lazarus-ide.org which is a cross-platform IDE that uses a Delphi-compatible language (i.e. object Pascal). I was pretty happy to see that it has a Mac version of the IDE and I will freely admit that I prefer to work on MacOS for a variety of reasons. Among them is usually ease of installation and Lazarus completely fails on this count in my opinion.
Let’s start with installation. The Lazarus website takes you to a SourceForge repository that has three downloads. fpc is the compiler, command line tools and non-visual components. fpcsrc is the sources of fpc and its packages and you need that for code browsing. And then finally there is the lazarus IDE itself with visual components and help files.
First issue is that none of the Package files are code signed which means you automatically have to work around Apple’s security. Not hard but still it doesn’t give you warm fuzzies right off the bat. I forget which step made me do this but I had to upgrade to the latest version of Xcode and install the Xcode command line tools.
Then there was the issue that the Lazarus downloads doesn’t included a Mac version that will run on newer Mac systems. So you end up going to the Free Pascal Compiler repo on SourceForge to get it to install.
Finally, you get to the point where the Lazarus IDE installs and then you get to the configuration screen. As you can the FPC sources can’t be found. But wait, wasn’t that part of the big three downloads I did to begin with?
In the long run no amount of reinstalling or internet searching could solve this problem. There does happen to be an entry in the ComboBox at /usr/local/share/fpcsrc and when you use that option a dialog warning you “Without the proper FPC source code browsing and completion will be very limited.” But it lets you ignore it and actually open the IDE. For now we’ll ignore that the debugger doesn’t appear to exist either.
A blank project appears including a blank form (Form1). The component library window is spread across the top of the window with 15 tabs to break it up. In the Standard tab double click on the TLabel adds it to the form. From there you can drag the control to the location of your choice.
Things go very downhill from here. The label is selected and the eight handles appear and the mouse cursor changes when hovering over them. One would think that you can simply grab the handle to resize the control. Alas, I could not with the label even though I could with the other controls. I couldn’t even change its width from the properties list.
The properties list is pretty standard. All of the properties are listed in alphabetical order which I can live with but I definitely appreciate the grouping that Xojo does (although I still prefer the older Real Studio properties list to the Xojo Inspector). Logical groupings make life easier in a properties list.
A tab control on the properties list also shows the available events for the control. If you click on the right side of the event I immediately get an error “Error: include file not found ‘typshrdh.inc'”. Um…sure. Anyway, at this point I can’t do much more without getting these setup properly.
After spending a couple of hours over the course of three days I’ve given up. My Google-Foo is pretty strong but I keep getting nowhere. The directions I’ve found are pretty minimal and I’ve done what they say I should be doing to no avail.
All of this tells me several things. The lack of documentation, particularly for MacOS, tells me that that it’s not well maintained for MacOS and I don’t think it’s used by Mac developers very much. And this is long before I get into evaluating the language and libraries that are available for it.
For ease of installation and getting that first Hello World application up and running Xojo is by far the clear winner. Look, I don’t expect an open-source project to be as easy to setup as a commercial tool so perhaps it’s not a fair evaluation. But it is one of my criteria because I have clients that take over development of their projects after we do the initial work. So if I’m having these types of problems I can’t imagine a less skilled developer having any less.
If you’re using Lazarus on the Mac I’d love here from you. Drop me a line at email@example.com and perhaps we can get me past this hurdle so I can do a real evaluation of the tool.
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.
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 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’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.
Xojo 2019 Release 2 arrived this week, and to say that this is a massive release would be an understatement. Among a large number of bug fixes and IDE enhancements is the first release of API 2.0. With every release I say that you should test your projects thoroughly, but in this case it needs to be mandatory.
API 2.0 is Xojo’s latest attempt to make the framework consistent across all the classes and should be easier to learn and use than the old framework. The properties, methods, and event names of practically every single class have changed. Some have changed in subtle ways, and others in a bash you over the head fashion. What might be even more important is that classes that used to set an error bit or error code will now throw an exception.
Some of the most basic things in Xojo have changed. Declaring a variable has changed from using the Dim keyword to the new Var keyword. Declaring an array is the same but resizing it is now accomplished like this:
//Declare the array
var arNames() as string
//Set it to a new size
//Clear the Array
Every Window and Control that comes with Xojo 2019 R2 has new events. Open, which admittedly can be confusing, is now replaced with the equally confusing Opening event. Close is Closing and so on. I have yet to find any direct mapping document of old events to new events and that’s a crime.
A complex control like the Listbox has dozens of events, properties, and methods and nearly all of them are renamed. Some make sense. ListBox.ListCount is now ListBox.RowCount. But ListBox.EditCell is now ListBox.EditCellAt. To append a row to a Listbox you still use ListBox.AddRow, but to insert a Row you substitute ListBox.InsertRow with ListBox.AddRowAt. I simply don’t see why AddRowAt is easier to remember than Insert (I could argue that InsertRow makes more sense).
Some changes I strongly disagree with. For example, Arrays in the old framework were simple enough to add items to:
dim arMyArray() as integer
arMyArray.Insert 0, 2000
With API 2.0 the Append and Insert methods are replaced with AddRow and AddRowAt. Again, one can argue that removing Insert and replacing with AddRowAt is simply a poor use of the English language.
Pre-API 2.0 Projects
The good news is that existing pre-API 2.0 projects will work with only a few modifications. In our projects (Task Timer, Shorts, ARGen) there were little to no changes required to get them to compile in R2. And the good news is that you can continue to use the old API in R2. The Code Editor AutoComplete will show you the old API and the new API with the old API call in Red and show you the new API 2.0 method or property.
Starting a new project in R2 will only show you the new API and events. Certainly one of the drawbacks is that Xojo projects created in R2 are not backwards compatible. Xojo has never really guaranteed that newer versions would be compatible and this is one of those cases where it’s simply not possible (theoretically if you never implement any events it will work).
My advice: Treat R2 with kid gloves and make backups of your project files before you play with it.
Let’s talk about events for a bit. I’ve already hit on the Open event that is replaced with Opening and Close that is now Closing. I find nothing wrong with the new event names, per se, but anyone with an older project, or someone taking an older class and putting it into R2 must be extremely careful. The old Open and Close (and other) events will fire as expected – until someone implements the new API 2.0 event like Opening. Once you do that the old event no longer works. This has the potential of really messing with legacy products that use the old Events and new users not knowing the difference and implementing new events and crushing functionality.
Frankly I find events to the most problematic part of API 2.0 since I, as a provider of 3rd party code, can’t enforce that a Xojo developer use the new or old events. It’s going to be a nightmare for the next couple of years (maybe forever?) as new people find old classes and implement them in their new R2 projects. Events cannot be coded out with #if statements. There is simply no way to control which events to use in a mixed environment.
If you’ve created your own control subclasses with custom events let’s hope you don’t have naming conflicts with the new event names. The only way to solve this is to change your Event definitions in a pre-API 2.0 version of Xojo.
Despite being a great idea, the Text datatype from the Xojo framework never really caught on. As part of API 2.0 many of the Text methods have been brought to the String datatype. As with all the other classes nearly every method and property name has changed in some way, shape, or form.
The biggest change, and perhaps the most problematic, is that the string functions are now zero-based. The first character of a string is zero and no longer one. The InStr method has been replaced with IndexOf (bad name in my opinion) and instead of returning a zero if the search string is not contained it will return a -1. Don’t get me wrong, this is a good change in the long run, but when developers are converting their projects from pre-API 2.0 things like this are going to bite a lot of developers as it’s not a direct replacement. You can’t just simply use IndexOf to replace InStr because it will break your code. Expect some grumbling about this from the greater community.
Date and DateTime Classes
Xojo has deprecated (not removed) the existing Date class and has created a new DateTime class. This is mostly a rehash of the Xojo.Core.Date class but it uses Strings. The new DateTime class is not a direct replacement for Date since the DateTime class is immutable. In effect if you’re doing any sort of date math you’ll need to use the new DateInterval class. The DateTime class also does not have TotalSeconds but instead has a SecondsFrom1970 property. To get a New DateTime you use the Now shared method instead of creating a new instance of it.
The FolderItem class was significantly updated on macOS and uses Apple’s more modern API’s. This should make file operations significantly faster on newer versions of macOS. FolderItem.AbsolutePath has been removed (it’s been deprecated for a while now).
Because of these changes you really need to be careful with URL Paths with query parameters. The behavior between R2 and earlier versions of Xojo has changed significantly.
The database classes have some welcome changes that have huge implications. Besides new classes, methods, and properties for everything to do with the database, any interaction with the database has the potential of throwing an exception. In the old API you had to explicitly check for the Error property. Now it will throw an exception that you have to capture and handle. This is both good and bad.
With ActiveRecord and ARGen we’ve been throwing exceptions for years when we found the database error property to be true. So not a big change for us, but for anyone that’s ever checked to see if a RecordSet is nil will be surprised when the exception is thrown. This is guaranteed to get your attention (many people never checked for the db error anyway!) but it will be a pain for many developers. Database code will need to be in a Try-Catch block, and doing this in a proper Transaction will cause some structural changes to your code.
RecordSets are deprecated. Long live the RowSet! RowSets are returned from Database.SelectSQL and instructions are passed through Database.ExecuteSQL. This is in contrast to the old SQLSelect and SQLExecute methods respectively. I can guarantee that I will mix the old and new versions up for many years to come.
PreparedStatements are no longer needed as they are built-in to the SelectSQL and ExecuteSQL statements. You no longer have to Bind the DataType and Value as the class does it for you. This is similar to what iOSSQLiteDatabase has done for years and hopefully this gives everyone more incentive to use them. PreparedStatements were a pain to use and this new method is considerably more streamlined.
One word of caution to anyone that uses the MBS SQL plugin: You must update to the 19.4 version as the database class changes required the plugin to be updated. Older versions of the plugin will fail silently and may cause other plugins to not load properly.
URLConnection received some updates. In Windows 7 and 8 it picks up proxy settings. It also no longer hangs a Windows application when downloading large files or content. In Linux a ResponseHeader that no longer exists doesn’t crash the application. They also made the ResponseHeaders an iterable function allowing the use of For-Each loops.
They (finally) added BeginTransaction to the Database class. It’s silly that this hasn’t been part of the framework for the past decade.
The Code Editor received some interesting changes. Pressing Shift-Return on an existing If-Then or If-Then-Else will now break the statement into multiple lines. On a comment line holding the shift key and pressing Return automatically adds another line of comment.
The Layout Editor has some changes too. It now has a control to switch between Light and Dark modes.
There is now a number of new Refactoring Tools available and they fixed a number of bugs in the refactoring tools. They added a new code assistant for wrapping the selected code in an #if XojoVersion block (handy with all the new API 2.0 changes). The Add Event dialog has been updated to allow adding deprecated events when a checkbox is selected (deprecated events are in red). In the same light you can right-click on an event in the Navigator and choose to convert it to the newer API 2.0 event.
The FileTypes editor and Associated File Types editor have been combined into a single editor. File Type Roles have been renamed to None, View, Edit, and Execute. For MacOS you can set if the File Type is unique to the application.
Catalina may force many developers to upgrade sooner rather than later. The SelectColor function was updated in R2 to no longer use an outdated API function. Using SelectColor with an app built before R2 will reliably crash on Catalina. The only solution is to build with R2 or use NSColorPanel yourself with declares or the MBS plugin.
Maybe I’m just an old school person and a curmudgeon but I find the lack of Old to New documentation extremely disappointing. Xojo has a Deprecated list at https://docs.xojo.com/Category:Deprecated but I find it worthless. I’d like to look at a single class at a time and have all of the events, properties, and methods showing the old name and then the new name along with any comments. I realize this is a lot of work but I’m surprised that Xojo didn’t create this documentation BEFORE doing any coding to use as their coding bible.
Any old example, sample project, old forum post, Google search result is now obsolete. BKeeney Software’s 65+ hours of Xojo training video that covers a good chunk of the Xojo framework is now practically worthless. I will be shutting the doors of the training site because it’s not worth my time (at this point) to redo over 200 videos. Xojo needs to convince me otherwise.
Deprecation Items That Have a Replacement
The Xojo IDE tries to be helpful in converting your projects to API 2.0. There will probably be a handful of things that will flag compiler errors in your pre-API 2.0 projects. If you Check your project you will get a rather large list of items that are deprecated that have a replacement. This list can be overwhelming and I recommend NOT doing global search and replace on these items because the code is sometimes quite a bit different. Good luck!
If you have an existing project I would be very carefully with R2. Sure, try it out on a *copy* of your project, but don’t expect to use R2 right away. I’m almost sure that there will be changes to fix bugs and strong community objections to certain things. We already know that Reporting and XML was NOT done for R2 and I’m sure we’ll find other things along the way too.
For developers using R2, please be patient. Get used to the question: What version of Xojo did you start with? The community is going to struggle with the changes for a while and we have no idea that his means.
All in all I think there are some good changes to Xojo 2019 R2 but I also think that there was a lot of change merely for the sake of change. I’m not convinced that all the changes were for the better. But really, only time will tell.
IDE received quite a few tweaks
Lots of bug fixes and enhancements
API 2.0 is mostly consistent with naming (with some oddities for sure)
Lots of bug fixes and enhancements
Exceptions now thrown instead of having to check for error codes
FolderItem significantly upgraded for macOS
DateTime added as a replacement for Date class
API 2.0 is not entirely done yet with more changes to come
Change for the sake of change in some cases
Exceptions for common and expected errors is not ideal
New String methods are not drop-in replacements because they are zero-based
API 2.0 event handling prevents API 1.0 events from being raised
Documentation woefully incomplete
All existing documentation, examples, videos are obsolete
What topics would you like for me to talk about with API 2.0? What do you like and dislike about API 2.0?
At XDC 2019 my session was titled Xojo Design Mistakes (the alternate but way longer title was ‘Thankfully time travel doesn’t exist or my future self might travel back and murder my younger self for the stupid coding mistakes I’ve made’). These are things that I’ve discovered over the years, both in my own projects and in other peoples projects that are just plain wrong or less than ideal. This will be an on-going series since I had well over 50 slides and left about 150 out. So when I get bored I’ll bring these topics up.
Don’t use GoTo – ever. GoTo is a holdover from the old BASIC days where code was unstructured and you needed to manage flow-of-control. Old BASIC programs used a ton of GoTo statements because, well, you just had to. It was the only way to get anything done. Xojo uses a modern BASIC syntax but it’s fully object-oriented code and still has GoTo as a reserved keyword and it still functions.
Xojo has many ways of doing flow control. There are multiple ways of doing loops with While’s, Do-Loop’s, For-Next’s, and we control those loops with keywords such as Continue, Exit, Return. Since we have methods and functions too we can exit those by calling Return at any point in the method and the code resumes execution at that point. GoTo just isn’t needed any more.
And yet GoTo still exists. I recently ran across this code in a project we’re updating for a client.
As you can see we are in a fairly typical For-Next loop iterating through a ListBox. The first line into the loop we check if we’re closing the window and if we are we call GoTo bale which takes us to where bail: is. Bail is at the bottom of the method and we’re doing nothing afterwards (the last two lines are Exception handling in this method and aren’t called).
This is such a poor example of Xojo coding. We can use Exit to accomplish the same thing since Exit will immediately exit the loop and since there would be nothing after the loop it would simply leave the method entirely by simply calling Return. There’s no penalty for using either Exit or Return.
Honestly, I have no idea why the original developer did this. I think they came from VB6 where code like this was pretty common, but even in that language there were much better ways to do the same thing. So I will call this lazy coding because the developer didn’t use the best way in Xojo.
Using GoTo like this is potentially risky too. Feedback case 24710shows that using GoTo may cause a memory leak because the compiler may skip cleanup code. I think the above code is safe but I could see if we loaded oNote before the GoTo exiting the loop it would be dangerous. But even still, if GoTo is outdated, not recommend, and dangerous on top of all that why use it? I can think of at least three ways to make this code safer and better.
At the end of the day, If you’re using GoTo – don’t. Refactor your code so it makes use of the modern Xojo calls. It’s safer and the right way to code in Xojo. Your future self will thank you.
There are bugs and then there are bugs. Not all are created equal and certainly not all are worthy of a dot release. But when a serious bug comes to light you have to take it seriously.
Feedback 55596 is a perfect example of this. If you use Listbox.CellTextPaint or Listbox.CellBackgroundPaint your app will leak memory. Leaking memory is bad to begin with but since the Listbox calls these events frequently. Losing 64 bytes per call adds up quickly.
I was going to do a release today for a client using 2019 R1. This was the first release where Windows drawing was as fast as older versions of Xojo. Prior releases of this product had to be built with 2017 R2. So now what do I do? I’m damned if I do a build and I’m damned if I go back to 2017 since we have to retest everything.
Xojo Inc. doesn’t seem interested in doing a dot release. On the forum Greg was quoted as saying, “…doing a point release is not an insignificant task and takes resources away from making progress on other things, never mind the additional stress that comes with it.” Who cares if it’s work on their part? Seriously, if I can’t use the current public release then why am I here? It’s bad enough I’ve been chasing Xojo versions for nearly two years with Windows drawing.
This is part of a much bigger issue that many at the Xojo Developers Conference discussed a few weeks ago. Xojo has always been a lean organization and many times I’ve felt that it’s been quite anemic. But an important bug and a public release to fix it shouldn’t be a major stress inducer to the developers. To me this says there are too few developers and too much work on their plate.
For what it’s worth, the bug is marked as fixed as of May 14th. It’s still too early to tell if we’ll get a dot release for such an important bug fix. Maybe R2 is just around the corner but I don’t have time for a 30 to 60 day beta period. I need this fix now.
The 2019 Xojo Developers Conference (XDC) wrapped up last Friday. It’s my favorite event of the year and while I’m sure many people think that I’m an extrovert I can only play one for shorts periods of time. I’m enjoying the peace, and more importantly, the quiet at home today hoping to recharge my social battery before having to attending a high school robotics meeting, mandolin orchestra rehearsal, and a mandolin concert this week. Oh, and I have to pick my sone up in Chicago. No pressure to get things done, no?
XDC is my favorite time of the year. While attendance was down this year (more on this in a bit) a lot of people from Europe made the trip over to Miami. It was good to see a lot of old friends and awesome to make some new ones. To me, it’s the connections you make and the stories you hear from other Xojo developers that is inspiring in so many ways.
The keynote address by Geoff was…underwhelming. It was the usual mix of how the community is doing, what they’ve done since last XDC and what they’re working on. As expected they’re working on Web 2.0, API 2.0, Interops, and Android. The best timeframe Geoff gave for anything was ‘soon’. At least we didn’t have the mental gyrations over ‘priority’ and ‘important’ like last years XDC.
It’s hard to show much for big ticket items like Web 2.0 and Android. These are big multi-year projects that you just can’t show off without having significant work done on them. For Web 2.0 the demo that Greg gave seemed pretty solid but then there weren’t a lot of details. It did seem solid and that was good news in my opinion. The Android demo, on the other hand, looked much more scripted and not nearly as smooth – it had the feel of ‘this is something we know works and we’re not going to do much outside the script’ feel to it. For API 2.0 there wasn’t much to show except some before and after code snippets.
So on one hand the keynote wasn’t all that exciting. On the other they didn’t have much to show because it’s work in progress. They threw some numbers out like 70% complete in which the pessimist in me said, “great, that means there’s still 70% of the work left to be done.” The people around me at the keynote had some similar thoughts as mine. To be fair, ‘completion percentage’ means something different to everyone.
I am very excited about Web 2.0. It’s a rewrite of the entire framework. You have to keep in mind the original framework was done ten years ago and the web has changed drastically since then. The work they’ve done on theming is going to make our Xojo web apps look fantastic and since more processing is done on the client side it should make apps a lot more responsive. We’ll have a LOT more controls to play with too.
To be honest, I’m pessimistic about Android. I’m sorry, but two years later we’re still waiting for a release. With work still to be done on the Xojo framework items (think FolderItem) and the debugger I just don’t see that happening by the end of the year. Prove me wrong, Xojo.
Jim Meyer’s presentation on using AWS and Google Machine Learning API’s with Xojo was fascinating. Using their API’s it’s easy to do text transcription from text and video, recognize images, do facial recognition and much more. It was by far my favorite session I attended. I can’t wait to get the example projects and try them out on a few things.
I didn’t attend this session but attendees were buzzing about Monkeybread Software’s DynaPDF plugin. The big news was that Unicode support will be added by the end of the year and that we’ll be able to create PDF’s by drawing directly into the Graphics object provided by the DynaPDF class. All good news.
Michael Dettmer showed an interesting way to quickly create database applications for Xojo using an Apache Velocity and his own open source software called CAPP, or Computer Aided Program Production. Essentially you create templates for the various things you want and it creates a project for you. The drawback is you have to use Apache Velocity and Java to do some of the coding. I’m not doing the demo justice but it did look a bit more complex than many Xojo developers might be capable of. However, consultants might find this tool essential since you do a little work up front to create a database application. You can read more at https://capp.systems
Yousaf Shah had a great session on how to get happy customers, successful projects, and live stress free. Yousaf said that developers aren’t always the most empathetic people and it’s hard to put yourself in the client position. When mistakes are made you don’t have to admit a mistake but saying, “I’m sorry you feel that way,” is important. He also spent some time showing how we can go from features to tasks (wrong word) so that you can get a better feeling for what the client really wants while also letting them be in control driving what’s important to them.
One session that I thought was fairly depressing was the Ask the Engineers session. Greg, Travis, William, and Paul did a good job of answering questions from the audience but it was shocking to see that few of developers working on the product. They’re one heart attack away from major portions of the project to be delayed. If you didn’t know, Paul has been moved from his Evangelist role to an engineering role. Since last XDC Norman was let go and Joe (compiler) has moved on to another job. Geoff can say all day long that they have enough resources but I just don’t buy it. More engineers means more stuff gets done.
Not giving us any timeframe for releases is one reason why I think attendance was down this year. If you don’t think there will be any big news and hands-on with cool, new, stuff then what’s the point of the attending? I disagree with the reasoning but I understand it when it’s a significant cost to attend.
No XDC in the United States next year. They are looking at something overseas. No word on where they’re looking but since MBS has conferences in Germany that are well attended I suspect some place other than Germany. But who knows? Like everything else they’ll tell us when they tell us and BKeeney Software will most likely be there. After all, it wouldn’t be a Xojo Developer Conference with us being there! See what whenever and wherever the next one is held.
The Xojo Developers Conference (XDC) is just around the corner. In less than two weeks Xojo developers from around the world will gather in Miami to talk Xojo for three full days. The speakers have sent in their slides and gotten feedback from Xojo and flight and hotel reservations made.
This is my favorite part of the year! Really. BKeeney Software has been around for nearly 18 years and in that time I’ve gone to many Xojo Developers Conferences including those sponsored by Xojo, sponsored by Monkeybread Software, and even held a few I helped host with the defunct Xojo developers user group.
Many of the developers that attend are my friends. Many more are colleagues, and competitors. Some are current and old clients. Some of those clients I met at XDC looking for developers for their project since there will be no greater concentration of Xojo developers on the planet!
You’d think that with as many developers conferences under my belt there would be nothing new to learn. I disagree since Xojo is always morphing into the next phase of its existence. When I started, 68k Mac apps were transitioning to PowerPC. They added Windows and Linux targets. They added Cocoa for MacOS, 64-bit builds for Mac, Windows, and Linux, the ability to create web applications, Raspberry Pi apps, and mobile applications for iOS.
I expect this year we’ll learn a lot more about Xojo for Android which will be a significant new target and make iOS that much more relevant with Xojo. We’ll learn about InterOps that aims to make adding libraries much easier for iOS, MacOS, and Android. And I’m sure we’ll see a lot about Web 2.0 that will make Xojo web applications more powerful and more robust.
At the end of the week, it’s always sad to go home. The bonds you make while sitting across the table from someone at a meal, or over drinks at the end of the day, is something that you can’t get in the forums, email, or via videos from the conference. Don’t get me wrong, the Xojo forum is one of the friendliest developers places I’ve ever experienced, but there is something truly powerful about chatting with people and being able to read their body language and talk about their developer experiences that far outweighs the convenience of the electronic venues.
If you have the means I highly recommend making it to XDC. It’s well worth it. You’ll get to meet some awesome people, learn a bunch of new things, probably see some alpha or beta of new features, and overall have a good time with your extended Xojo family.
If you’re going and we haven’t formally met, please feel free to stop me and introduce yourself. Remind me how you came to find me and what products, if any, you use. Tell me what features you like, or don’t like. Just say hi and then go talk to the many other Xojo developers there – you might just find friends for life.
Of course I’ll blog about the keynote and the cool new things that I see at the conference. See you in Miami!