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!
Xojo 2019 R1 was released today. This is the 2nd release in a row where there is not a dramatic number of new features but quite a few bug fixes and enhancements. Let’s dig into what’s changed in this release!
The big change in this release revolve around the URLConnection control. The HTTPStatusCode property is now available for both the Send and SendSync calls. The control now appears in the library. It now yields to other threads. Send requests are now closed before the ContentReceived and FileReceived events are fired. The string encoding for the ResponseHeaders is now consistent across platforms. It also now automatically handles compressed content-encodings in Windows and Linux (just like MacOS does). The TimeOut property now works (before it always did 30 seconds). Error messages are no longer empty in Windows. The ReceivingProgressed event now correctly reports the total bytes. The response headers are now updated property when a request is made. The SendSync no longer intermittently returns empty strings in MacOS.
The licensing has changed for Raspberry Pi. The license for Desktop and Console applications on the Pi is now free!
There are some other new items. The list is small but significant. The first is that 32-bit Windows builds can now set HiDPI and supported versions properties in the manifest file.
The TextArea control for Windows 8 (or newer), and Linux now support system spell checking. This matches the behavior on MacOS.
The Text datatype now has target appropriate EndOfLine properties. If you use Text you’ll no longer have to create your own EndOfLine constants.
The IDE added the ability to switch between Computed Properties and manual Getter/Setter methods. There is a new menu item when right-clicking on a property. In addition to the standard Convert To Computed Property there is a new menu item called Convert To Method Pair which creates two overloaded methods. For example, if you have MyProperty as Integer and select the Convert to Method it will create one MyProperty method that returns the integer value and another overloaded method that accepts an integer value with an assigns. So it looks like to consumers of this property as if nothing changed.
The constants setting has been changed from Dynamic to “Localized.” This creates a new grouping in the Code Editor called “Localized Strings”. It’s still a constant but it better reflects that it’s localized and should make it easier to visually see if a string is localized or not as there was no easy way to tell before.
There are 25 changes and 162 bug fixes for Xojo 2019 R1. Here are what I feel are the significant items:
The ODBC Database plugin now works better with 64-bit builds. Date fields in MacOS now work properly. In 64-bit Windows updating a binary/image column no longer fails with an invalid precision error.
The MySQLCommunityServer plugin no longer crashes when has certain field types and originated from a PreparedStatement.
The SQLiteDatabase no longer crashes when out of memory situations arise – an error is now generated.
Calling an OpenDialog from within a thread now properly raises a ThreadAccessingUI exception. I’m actually surprised that this wasn’t flag a long time ago.
StringShape rotation is no longer incorrectly offset. The original Feedback report was for Linux but it appears this affected other targets too.
The Window/Canvas Backdrop picture now draws correctly in HiDPI. This doesn’t affect me directly but this is the first time in several years where Canvas drawing in Windows seems really solid. I’m in testing right now with a client app that had been held back in 2017 R2.1 because of Windows drawing performance.
GroupBox caption in Windows now properly draws the size, bold, italic, and underlines styles instead of ignoring them.
A bunch of work was done in the Code, Constant, Layout, and FileTypes editors. The Inspector and Library received a little love too.
So far I’ve found this release to be solid and the major updates to URLConnection now appear to make it worthy of investigation. I’ve not used it enough, yet, to recommend it but I think most of the major bugs are worked out. The number of bug fixes and enhancements makes R1 a worthwhile upgrade.
I think this version is worthy of your time and effort to try out. As always, you should really test Xojo out on your projects, in all targets, to make sure it works as expected. Some of the bug fixes in this release might mean you have to get rid of some workarounds you’ve come up with (thinking of the StringShape rotation fix here).
Let’s hope that the major new features (like API 2.0, Web 2.0, and Android) can be staggered so there there isn’t a flood of new things in a single release. Too many new things makes it hard on beta testers.
Have you found any showstoppers? What are you most happy about in this release?
I hope everyone’s holiday season was good. We’re approaching the end of 2018 and I find it nice to reflect on what’s happened and what we’ve accomplished this year.
Let’s start off with the blog posts. I did 41 (well now 42) blog posts in 2018. Five were about Xojo releases. Four were BKeeney Software product releases. Four posts were about the Xojo Developers Conference. The rest were a variety of Xojo related topics.
The most highly commented blog post was from June called Chasing Xojo where I lamented that Xojo, at least until that point, seemed to be a less stable when it came to Windows and Linux due to major revamping of the drawing systems on both platforms. In Windows, Xojo doesn’t flicker as much but the struggle to get speed was a concern for all of 2018. In Linux, the switch to GTK 3 wasn’t as smooth as we could have hoped.
The most viewed blog post was from August called Xojo 2018 Release 2 where I did my usual review of the most recent release of Xojo. I heavily criticized Xojo for their poor documentation in that release. I received plenty of blowback on that one. But I think the end result is that R3 and R4 documentation was much better.
We released two new products with BKS Report Studio and BKS Tab Control. Report Studio is our reporting utility meant for end-users for macOS and Windows and it was built using the award winning Shorts reporting classes (also a blog post). The Tab Control is a canvas subclass that replaces, and extends, the built-in Xojo tab control in many ways and was our attempt at replaced the old CustomTabControl that many use but is unusable for HiDPI apps.
The other major release of the year was ARGen 3.0. ARGen is our utility to create Xojo projects that creates ActiveRecord objects. Among the many changes was the ability to generate ActiveRecord objects for iOS projects, supporting GUID primary keys, and the ability to include Audit Trail, Localization, and Database Update modules that help in many products. We use ActiveRecord in practically every project and having the ability to generate some basic desktop and web UI is a huge time saver.
2018 sure seemed like a mixed bag for Xojo. The Windows drawing issues took up a good chunk of the year and I think R4 was the first solid Windows release (although I still have 2 client apps that won’t remote debug in R4). I can’t imagine the amount of effort that Xojo and the community put into getting Windows drawing fixed.
64-bit remote debugging became a reality for all targets this year. 64-bit compiling isn’t the huge gain that many in the community hoped for but then we always want more. We just have to remember that 64-bit doesn’t necessarily mean ‘faster’. At least the debugger works and that’s not nothing.
Dark Mode came soon after the release of Mojave. The IDE works in Dark Mode and we were given many of the tools to implement it in our own projects. Dark Mode only works in MacOS but some are already clamoring for it in Windows too. It’s still to early to tell if Dark Mode is a hit on Mojave much less in xojo.
What is 2019 going to bring us? For one, we’re almost finished with a fairly significant update to Formatted Text Control and after that’s released we’ll start with an even bigger version 4 update to the venerable word processing control to bring it up to date and extend its capabilities to make it even more powerful.
We have a number of large consulting projects that have been in gestation for many months and years. It will be nice to have a big project or two to keep us busy.
With the release of Web 2.0 I will redo all of our Xojo training videos related to web. They’ve been outdated for a while but it’s not worth redoing the videos until Xojo releases Web 2.0. If they release Android I’ll start on at least some intro videos for that too. This might finally be the year that I redo the remaining Real Studio videos. No doubt I’ll redo them just before a major IDE change. 🙂
What do I expect from Xojo? That’s a tough question to answer since they’re so damn secretive now. I expect Web 2.0 to show up in time for XDC (so maybe release 2?). I think it will be pretty solid in the first release but it wouldn’t expect it to be good until the following release.
I also think that at XDC we’ll get an alpha of InterOps but not anything other than another dog and pony show for Android. Targeting another platform is long and tedious process and involves some serious IDE work. How much of the iOS editors can they use? I can only guess but at first blush I say not much.
Some of Android’s success may hinge on getting iOS to use the global framework and away from the Xojo Framework. Nothing like rewriting an entire framework while keeping backwards compatibility. The more I think about it the more I think the iOS rework is put on hold until Android is released.
Which leads to API 2.0 in general. We’ve already seen some of the first new controls to use API 2.0. URLConnection was introduced in 2018 R4 with mixed success. I would expect more API 2.0 controls to show up.
So what do you think? Was 2018 a successful year for Xojo? What do you see happening in 2019?
Xojo 2018 Release 4 hit the internet this week. This relatively small (84 bug fixes, 21 changes, 5 new items, and 11 doc and example changes) update is a nice end of year release that may or may not satisfy your Xojo dreams. Let’s get into the highlights.
Of the new items list the big one is the new URLConnection class. The URLConnection class works with the HTTP 1.1+ protocol and works with http and https connections. This is a replacement for the Xojo.Net.HTTPSocket and brings back one of the things many developers missed about the old HTTPSocket class – Synchronous communications – using the SendSync method.
SendSync is a concession by Xojo with the caveat that the application may appear to freeze while running this method. The regular, and probably the better, Send method is asynchronous and does not freeze the app. Admittedly the async way is the better way but for many developers the synchronous method is easier to implement and ‘good enough’ for their use. Still, consider using the async method.
The Screen class now has the ScaleFactor property. There are two new global constants: AppSupportsDarkMode and AppSupportsHiDPI that are pretty self explanatory.
iOS builds now use the iOS 12.1 SDK. macOS builds now use the 10.14 SDK for 64-bit builds.
There are couple of changes that are noteworthy. The first being that the Windows IDE can now successfully build large projects for Linux 64-bit and ARM targets (frankly I didn’t know this was a problem but I bet that ‘large’ is the key word). Any remaining threads are now killed after the app.close event (possibly a reason why some apps in macOS crash after they quit?). EnableMenuItems no longer fires needlessly on every keypress in Windows. Lingua and Remote Debugger Stub have been updated to work with Dark Mode on macOS.
There are 84 bug fixes in this release. The more important ones (at least in my opinion): The Build folder is properly emptied between build runs. Remote Debugging to a Raspberry Pi no longer randomly crashes when stopping at a breakpoint. Browsers that have disconnected from the web app will now reload the web app so they don’t appear frozen. There are also a couple dozen IDE bug fixes to the Inspector, Navigator, Find & Replace and a number of the editors.
As with any new release you need to thoroughly test your projects before doing a public release. It was noted during the beta period that the Einhugur Search Control didn’t work properly in Mojave but has since been fixed. We had one large project not work when remote debugging from Mac to Windows but I haven’t had time to track it down. If you have found any new issues with R4 please submit a Feedback report right away!
I’ve been attending Xojo developer conferences for twelve plus years (don’t remember what my first XDC was – maybe 2004?). Each one is unique and the topics are usually interesting but do tend to be repetitive from year to year at times. The session topics for XDC 2019 seem to be more unique than past years.
Obviously Geoff will do his keynote address and talk about what they’ve done in the past year, what they’re currently working, and what’s coming up (sometime) in the future. There is a session each for Android, Web 2.0, API 2.0, beyond Linux, everything MS Windows, and more by the Xojo staff.
What’s left is an intriguing list of sessions that will be tough to figure out what I want to attend and which ones I can wait to see recorded (assuming they’re recorded again). I can’t remember an XDC I’ve looked forward to more.
Carol is doing a session on Database Topics for Programmers and I’m doing one called “Xojo Mistakes We All Regret Later”. My alternative title is “Thankfully time travel doesn’t exist otherwise my future self will no doubt come back to murder me for these stupid programming mistakes I’ve done.”
If you’ve never been to an XDC I highly recommend it. You will get to meet some of the best Xojo developers on the planet, talk Xojo non-stop for 3 (or more) days on end, talk to Xojo staff, and have fun. Of course that last point is mostly because of the first three. You won’t find a bigger concentration of Xojo developers on the planet!
I hope to see you all in Miami in the first week of May. What sessions are you excited about?