Whither My Reviews

Someone pinged me today and asked why I hadn’t done a review of Xojo 2021 R1 or R1.1.  The truth is that doing a review takes a fair bit of time and effort and I am NOT the person that should do these reviews any more.  

First, neither my employer or myself are using Web 2.0.  I still have *a* client using Web 1.0 and, well, nothing that Xojo is doing is helping me there.  Second, I have *a* client that has a Xojo iOS project and I do minor updates about once a year but I’m barely using anything new.  Third, I’ve avoided API 2.0 for the most part.

So what is there to review?  What valuable input can I give?  I don’t know.  I spend most of my time using Xojo to create and modify desktop Mac, Windows, Linux applications and console applications for those same environments.  Not sure I have a lot to say about the latest releases other than that we’ve mostly kept up to date with them.  I’m neither excited or disappointed by them.

They fix some things, they break some things, and it takes another release to fix what they broke.  This is a cycle that’s been repeated ad nauseam for…well…ever.  I just don’t have the need or drive to be a relentless cheerleader any more.

The blog was always a way to advertise our consulting services and developer products.  Since I have no need for either at this point I wonder how long I’ll keep the blog active.

Who knows, maybe I’ll find something I want to talk about with Xojo.  Or maybe some other language.  I’ve been doing some work with Go and it’s an interesting language.  Some of the brevity of C but with the strong typecasting of Xojo/Java but with really, really good concurrency options.  But Go is certainly not Xojo nor is it intended to be Xojo.  Some things I like.  Some things I don’t.

I appreciate people reaching out asking about Xojo reviews.  I think that ship has sailed and probably won’t come back to port for the foreseeable future.

How Much Time Have I Wasted Waiting for Xojo?

Many Xojo developers use a number of plugins because they do things that Xojo doesn’t or can’t do out of the box.  My current plugin folder has 49 items and at times in my 20+ years as a Xojo developer I’ve had closer to 60 loaded.  This begs the question how much freaking time have I waited on Xojo to load and then compile plugins?  Depending on how many different projects (and thus plugin sets I have) I work on I’d bet this results in over an hour per month.

Loading large projects is slow.  Some of the larger projects I work on take minutes to load.  That’s long enough to go grab a refreshment from the kitchen and get back to my desk before it finishes loading.  And that’s for desktop projects.  The last time I used Web (granted API 1.0) our large projects took even longer. I don’t have any Web 2.0 or iOS projects to compare the loading times.

Saving projects has definitely improved in the last couple of releases but in our largest projects it’s still slow.  And don’t get me going on all the time I (and our team) spend on getting rid of property changes in git commits. These stupid property changes has got to stop because it’s pissing us all off. Same with changes with shared external code between desktop and console applications. It simply sucks and we’re tired of it.

All in all I feel like Xojo is wasting a significant part of my day just waiting for things to happen or fixing things so git isn’t overwhelmed.  Coming up with faster ways for all those things should be priority number one because it affects everyone.  I dunno about the challenges to doing this but I feel like Xojo could be doing more. You’d think with the IDE being a very large project they’d feel the pain also of many of my pain points.

Really, all I want at the end of the day is to feel like Xojo isn’t wasting my time.

Formatted Text Control Has a New Home and is Open Sourced

One of the biggest shortcomings of Xojo is the lack of a full word processor control. The built-in TextArea doesn’t support images, hyperlinks, full RTF support, page layout view, and so much more. For many Xojo developers it’s a major missing piece. Early on in our consulting projects we found this shortcoming to be a major hindrance so we needed to find a solution.

Like most Xojo developers we turned to the third-party market and found Formatted Text Control that had been developed by Brendan Murphy of True North Software. When Brendan decided to leave the community we purchased the rights to Formatted Text Control and continued its development.

FTC was originally based on the Canvas control and when Xojo was updated to support Cocoa the canvas no longer did proper keyboard handling in macOS. After butting heads with Xojo they released the Text Input Canvas (as open sourced and to this day not properly documented) we had to scramble to update FTC to use it rather than the Canvas. Then we added Retina support, fixed any number of bugs and added features that I’d have to look in git to remember.

And then, like so many things in life, we didn’t use FTC in practically any projects. For years. And when that happens you tend to forget about it and it’s no longer an important thing.

In 2019 we made some serious effort to update FTC but it never went beyond some proof of concept projects and research. By the end of 2019 we recognized that consulting was slowing down to the point it was time to get a full-time job. Obviously all work on FTC stopped. In March of 2020 I found a full-time job (still doing Xojo development) and since then I’ve been slowly selling off products when I found a good home for them.

Today, I’m pleased to announce that Formatted Text Control has found a new home and will become open sourced! Dr. Brian Gaines has been an FTC user since before we purchased it in 2007 and it’s the basis for his suite of conceptual modeling tools. Since those tools will be open source in the near future, FTC will be open source as well. More information can be found at https://pages.cpsc.ucalgary.ca/~gaines/repplus/Code/

I believe that under the stewardship of Dr. Gaines and the open source community FTC will grow and change in ways that I never envisioned. It’s such an important tool for Xojo developers that I envision a lot of interest in it.

I thank Dr. Gaines for purchasing the rights to FTC and for open sourcing it. I want to thank everyone in the community that used FTC over the years, submitted bug reports, and asked those challenging questions on what FTC can and can’t do.

Happy coding!

Xojo Workers

Xojo 2020 R2 introduced the Worker class.  The Worker is Xojo’s way to use more cores and process data faster.  This is important because the Xojo thread class is cooperative meaning that it runs on the main thread, the same one as your application, and thus shares processor time of a single core.

Why do we use threads in the first place?  Generally it’s to do a lengthy process and you don’t want the user interface to lock up.  There’s nothing more irritating from a user perspective than to have your app do nothing for a few minutes as it chugs through something.  Threads prevent this but there’s a tradeoff using them because it means the overall time it takes to do the processing is longer.  So while the app remains responsive to the user it takes longer for the processing to complete.

So the Worker class is Xojo’s attempt at multi-processing.  The Worker class actually creates a console application that is placed in the application bundle/package and handles all the work of spawning the process and passing information back and forth.

I spent some time this week banging on the two Xojo Worker examples in both Mac and Windows and found some mixed and complex results.  My quick and dirty response about Workers and how good they are is: ‘it depends’.  Let’s start talking about the examples.

My first attempt was taking the Xojo example project PictureResizer and taking it through its paces.  I tested a folder with 1071 png and jpg files.  In all tests I used compiled applications because attempting this in debug results in the Workers using threads (more on this later).  For my workers I allowed 4 cores and up to 90% core usage to stress it out.  I used my 2015 MacBookPro that’s been BootCamped to use the exact same hardware.  MacOS side is using Catalina and Windows is using Windows 10 64-bit.

My initial results were this:

Mac:  274 seconds

Win:  115 seconds

My first question was why Windows was so much faster.  So instead of using Picture.Open I switched to reading the file in via BinaryStream and then using Picture.FromData.

Mac:  182 seconds

Win:  106 seconds

Better but still quite a bit different.  I suspect that Mac console apps are using a much slower Picture library than desktop.  So I then created a thread (using default settings) and found the following:

Threads:

Mac Picture.Open:  196 seconds

Mac Binary Stream:  200 seconds

Win Picture.Open:  124 seconds

Win Binary Stream:  205 seconds

I find it surprising that Picture.Open is considerably faster on Windows than Mac.  But I was still not satisfied with this result as it seems like Workers aren’t working as expected (pun intended).  So I created a new version and passed in 20 files at a time to the Worker.

Mac Picture.Open:  196 seconds

Mac Binary Stream:  176 seconds

Win Picture.Open:  115 seconds (no difference)

Win Binary Stream:  106 seconds (no difference)

So this says to me that the example is flawed.  Only processing one picture at a time isn’t very efficient.  There is some overhead to start a Xojo console application and it seems that on macOS it’s significant enough to barely make it better than using a thread.

For test two I took the WordCount example and modified it to be able to do the same processing from a thread as well as the Worker.  I also decided to test this without using any background process just for comparison sake.  I used 1320 Text files of random length.  Test results:

Mac

Worker: 13.41 seconds

Thread:  35.53 seconds

No Thread:  34.85 seconds

Windows

Worker: 19.09 seconds

Thread:  20.04 seconds

No Thread:  25.79 seconds

I think this example is a bit better since there is a ton of string processing that obviously takes a while.  On macOS you can see that the Worker is clearly better than the Thread and even the no thread.  In Windows there is not much difference and I’m not sure how to explain this difference other than that maybe starting new processes in Windows is slow but still it’s obvious that Workers are better than no thread and slightly better than using the Thread.  With something that requires even more work I would expect this to be more pronounced.

One of the beefs I have with Workers is that you literally cannot test them in the debug environment.  When you test in the debugger you’re really working in a thread.  One of the strengths of Xojo is that working in the debugger is mostly the same as working in the real thing and Workers break that paradigm.  It’s a shame but maybe Xojo can fix this in a future release.

My other take away from using Workers is that it’s not a panacea for everything just like using Threads is not perfect.  Workers are Xojo console applications and there is overhead to starting them.  Xojo does make them easy to use by handling the inter application communications but with only string processing available you might be better off using IPCSocket communication but that’s not without its tradeoffs too.

Using Workers will take some work on your part to make sure you’re doing it as efficiently as possible.  Is it better to process a number of things in the Worker or do them one at a time?  And of course if you decide on Workers you’ll have more ‘joy’ in testing them.  Overall, ‘it depends’ on your needs to know if Workers are useful for your application.

Xojo 2020 Release 2.1

Xojo released a dot release this week that contains some important bug fixes.  Arm64 and iOS targets as well as the new Worker class received a number of important fixes.  Let’s get into some of the details.

The new Worker class will now use the Error event if the main app tries to start a worker without the required Helpers folder instead of throwing a Nil Object Exception.  The Error event no longer fires when the Worker quits normally.

ARM builds for macOS has added complexity for Build Steps.  We now can specify architecture for CopoyFilesSteps.  Resizing an array of structures no longer crashes on macOS ARM builds.

The ODBC database plugin no longer fails to connect.

ParseJSON no longer raises a failed assertion when passed an empty string.

The new DateTimePicker uses the standard border width and the control height was changed for Windows.  The DateSelected returns a valid DateTime object in Windows.  On the Mac side the control now honors the Top value when displayed in Text mode and you can now set the SelectedDate property regardless of the Regional settings of the user.

TabPanel.RemovePanelAt no longer throws an Out of Bounds Exception if the tab exists.

iOS has a number of changes.  Global.Speak is now System.Speak, Graphics.Font returns a Font object instead of iOSFont.  UDPSocket usage no longer causes the app to terminate after unlocking the phone.  The Runtime module methods are now accessible.  Graphics FontSize, Bold, Italic are removed in favor of the equivalent Font class properties.  

All users should update to Release 2.1 because of these important bug fixes.

The Advantages of a Job versus Consulting

For the past 20 years readers have heard me talk about consulting and the joys and challenges therein.  Those blog posts aren’t wrong but for the past nine months I’ve had a full time job and my perspective has changed.  Here are some things I’ve learned.

I’ve told friends that I have a ‘real job’ now.  In reality, it’s way easier than consulting.  While I was consulting I was always worried about where the next consulting project was going to come from.  I didn’t realize how much pressure and anxiety that introduced.  As my youngest child (now a junior in college) will tell you we talked about work (i.e. consulting) ALL the time because it was an all-consuming thing.  We either talked about the current jobs, the jobs we were bidding on, or whatever hassles we were dealing with in regards to employees, insurance, cash-flow, etc.

With a full time job I don’t have to worry about the next gig.  Now I just worry about the next project my bosses give me.  Well, it’s not worry, really, since we have an awesome team of developers but it’s more intrigue and wondering how deep of a rabbit hole I’m going to go down since we deal with some pretty arcane stuff.  Not worrying about the future is a huge relief (as much as anyone can feel safe during a global pandemic).

Along with the full time job I have all the benefits that is tough with your own business.  A steady income is an incredibly good thing since as a consultant you’re either rolling in dough (figuratively) or have none.  Having a 401k is a big relief as I go into the later part of my career.  Paid time off is another huge benefit since as a consultant you don’t make any money if you’re not working.  I don’t have to worry about health insurance now either and as a small business you get totally screwed over when it comes to health insurance in the United States.  As a business it was our number one expense after payroll and it was a nightmare to deal with since practically every year there was a 20% (or more) increase in premiums unless you switch plans which is a huge pain in the ass since you worry about is the new plan the same or worse than the old one and how will it affect you and your employees.

I’ve always been thankful that Carol was wiling and able to do the HR, payroll, accounting, and contract side of the business as well as being an awesome project manager and data goddess (DBA) on top of all that.  Without that help there’s no way I would have lasted 20 years.  Me as a developer will always tell the client that ‘sure we can do that’ but it’s helpful to have the project manager say, ‘yeah, and this is how much extra it will cost.’  Someone has to be the bad guy with the client and it’s nice when it’s not you.

Consulting is very much a ‘drinking from the firehose’ type business.  You either have too much work or not enough.  There is no such thing as the perfect amount of business.  As a solo developer there’s only so many hours you can work so then you start thinking of having employees.  We were extremely lucky to have found the employees we had since most lasted five or more years and were exceptionally productive.  But dealing with employees is hard when it comes to hiring and firing (we had a handful that didn’t last 90 days for one reason or another).  They all had their strengths and weaknesses and some you can put in front of a client and others are less than ideal. Some are great at debugging and others are not. Some are great a developing new code and others are not.

I always felt that our employees were an asset to us.  I always tried to hire people that were smarter than I am (some would say this is a very low bar, I know) and some competitors were aghast that I would ‘train my future competitors’.  Having a good consulting employee is not the same as creating a future competitor.  If they were going to have their own business they’d have had one already.  I guess that’s always been one of my beefs is that people think that having a business is the same as having a job and they are far from the same (see all the arguments above).

Do I have as much time flexibility in my job as I did consulting?  It’s really hard to say during a pandemic since all of the robotics programs I’ve been a part of are on (hopefully) temporary hiatus, the music festivals we usually go to were cancelled, and we aren’t meeting in-person with the groups we usually do, and travel was restricted for most of 2020.  The company I’m with has people scattered across four timezones so there is a lot of flexibility in when people start and end work and we’re all remote anyway.  As long as the work gets done no one minds much when you start and stop or if you work weekends (I have quite a few coworkers that are being their kids teacher at this point and keeping them going via Zoom with their school teachers – honestly I have no idea how they do it).  But honestly, as a consultant I worked most weekends and did a fair amount of work at night too so I think I’m working a more reasonable and balanced workload now than when I was a consultant.

Consulting was fun and rewarding.  It has perks that are amazing if you have a good accountant and follow the rules and have multiple people that can help split the work load and responsibilities and you’re willing to put in the work (like writing blogs and developing products!).  The pain of consulting is oftentimes not worth the hassle.  Before you leave your full time job for consulting think long and hard about doing it and maybe think about all the negatives.  Maybe give me a shout to try and talk you out of it.

Xojo 2020 Release 2

The second major release of Xojo 2020 landed this week.  This release is filled with changes that will make many Xojo developers very happy.  Let’s dig into some of the details.

To say that iOS had a major update doesn’t quite do it enough justice.  iOS is now using the global framework so the old Xojo framework is now deprecated.  What this means is that code shared between web, desktop, and iOS is now considerably more compatible.  Plus, iOS is more complete with many of the missing classes, like XML, TCPSocket, RegEx, to name a few finally make their way to the target.  And, perhaps more importantly the String and Variant classes can now be used instead of Text and Auto (and their requisite pain of usage).

This release also lays some of the groundwork for Android.  No longer are the classes named with an iOS prefix but now use the Mobile prefix.  Presumably whenever Android is released there will be many classes that crossover just like Desktop targets do right now.

Another big change in iOS is the ability to use plugins.  This allows plugin developers, like Monkeybread Software, to add an extreme amount of functionality to iOS that simply wasn’t available until now.  Simply looking at the Monkeybread website shows some of their biggest items available for iOS including Barcodes, Compression, CURL, DynaPDF, GraphicsMagick, SQL, XL, and XMP to name a few.  Expect more and better things to be available to your iOS projects in the future.

How well does iOS work?  I can’t really tell you.  I have several iOS projects that use some of the iOSKit extensions and it will be a fair bit of work, I think, to replace everything.  The sad part is that I’ll likely be forced to update them soon so I can release some client updates.  I’ll keep you informed of my progress and pain when I do that.  If you have some current experience with this iOS release please share your experience with us.

The R2 release also brings us the new Worker Class.  The Worker is a way to utilize more cores on your machine than using a traditional Thread can use.  Essentially you’re offloading work from the single core that your Xojo application uses and it starts a separate console application to do that work thus utilizing more cores on your computer.  You could always do this on your own using a variety of methods but this automates the process.

You start by creating a Worker class object and implement the events Error, JobCompleted, JobRequested, and JobRun.  When you want it to do some work call Worker class Start method that then fires the JobRequested event.  This event is where you pass in some string data that the JobRun event uses.  When that job is completed the JobCompleted event fires passing in whatever string data you need.  The Error event is there to help pick up the pieces.

When run in the Debugger the worker classes is a thread but when it’s compiled a console application is placed in the appropriate placed for each target.  This means that there is a real difference between running something in the debugger versus your final application so it’s very important to test your results.  Since you’re limited to string data it’s probably not a great idea to pass large amounts of string data between your app and your Worker so maybe coming up with an intermediary (like a database file) might be useful.  

The Worker class is only available for Desktop targets for now and will presumably come to Console, Web and iOS targets in a future release.  I think developers will use this a lot and I expect some more advanced features coming to this class in the future.

With Apple releasing their first arm64 Mac’s just a few weeks ago this release also marks the first version that allows for native ARM applications as well as universal Mac apps (i.e. both Intel and arm versions).  The only thing I’m aware of that is not arm compatible is XojoScript and that will presumably come in a later release.  One thing to be aware of (this has been true for a while) is that to compile for macOS you need to be running Xojo on a Mac.  If you are running in Windows or Linux you cannot build macOS apps.  Xojo seems to think this is a temporary situation so hopefully that’ll happen soon.

The Graphics class received some love in this release adding LineCap and LineJoin properties.  It also adds support for Linear Gradient Brush, Radial Gradient Brush, Shadow Brush, and Picture Brush that allows a developer to do some really cool drawing effects.  This is long overdue.

For the first time in many years Xojo has added several highly requested and long overdue controls to the desktop.  New in R2 is a Search Field and a DateTime Picker.  The Search Field has pretty standard features.  The new DateTime control has the ability to be used in text-only mode or in graphical mode.  Again, it’s my opinion that these controls should have been added a long time ago but it’s nice that we have them now.

A few API 2.0 framework changes happened for TextField and TextArea controls.  The Value property is Text and the ValueChanged event is now TextChanged.  I think these changes make way more sense than Value and ValueChanged.

ColorGroups are now available for desktop, web, and iOS targets.

All in all this is another big release from Xojo adding new desktop controls, adding new capabilities to the Graphics class, the new Worker class, and doing a massive update to iOS.  The Xojo roadmap has their next big item as Android and with the R2 release it’s clear that they are getting close.  Will there be an R3 for the end of the year?  My spider sense says no but there might be a dot release to fix any major bugs that slipped through the cracks.

What say you Xojo developers?  Is R2 a good release?  What quibbles do you have with any of the decisions they’ve made?  Happy Coding!

BKeeney Shorts Has a New Home at Varcess

Reporting is one of those things that when you need it you want something that does 80%-90% of the work for you. For us, and many other Xojo developers, the reporting tool that’s built-in to Xojo just isn’t very powerful. So we built our own and used it practically in all of our consulting projects over the last 10 years.

Shorts has a report designer component that lets developers embed a report designer in their desktop projects. The banded report designer allows the user to change the fields, fonts, layout, etc. of a report as well as do some sorting, grouping, and also allow the user to ask for criteria before the report is generated. The report viewer component has versions for desktop and web v1. And if the report design can’t handle a report, you can fall back to doing extremely complex reports via code.

It seems like a lifetime ago, but Shorts was the winner of the 2018 Xojo Design Awards for Best Developer Tool. It was an honor to get the award and I’m always ecstatic hearing from Xojo developers on how they use Shorts and how happy they are with it.

Since I took a full-time job in the spring I’ve been looking for a new home for Shorts with developers that can take pride in its development and take it to new heights. I’m proud to announce that BKeeney Shorts has a new home at varcess. They use Shorts extensively in their own products and have already announced some new and exciting additions to it.

The developers at varcess are close to finishing inheritable report designs and a XojoScript debugger. Future Versions will add API 2.0, Web 2.0 support, sub-reporting, and a REST API reporting server. Whew! That’s a ton of new features and I can’t wait to see what Xojo developers do with them.

Stay tuned and check the xojo forum for future announcements. Existing Shorts customers will be informed via email and will receive a discount when updating to the next new version.

Please visit https://www.varcess.com for more information and to get updated demos in the future.

Xojo Can’t Math

Pop on over to Thom McGrath’s blog post about the ongoing saga of a 12 year old bug in the Xojo compiler. It’s an interesting, long, and complex issue that could affect your code if you use unsigned integers in your code. Admittedly, this bug may only affect a very small percentage of applications but it’s still a bug.

I think this saga exposes several things about Xojo. First, the way they use Feedback is fundamentally broken. For this particular bug they say it doesn’t affect many people because it has no points but because they’ve closed it the item won’t accumulate points. Voila! Nothing done about it in 12 years. Circular logic at its best.

Secondly, I truly believe that since they do not have a compiler engineer this bug won’t get fixed. Heck, most likely can’t get fixed because of lack of experienced personnel. Compilers are not simple things. I don’t buy for a second that Xojo has enough developers for the product they have.

The thread on the Xojo forums was long and contentious, and I don’t think Xojo did themselves any favors by arguing. While I appreciate Geoff talking to us in the forum it does kind of amplify the perception (reality?) that’s he’s not really listening.

I think I can say this with near 100% surety: We want Xojo to succeed. Many of us need Xojo to succeed for our careers and business.

Anyway, happy coding everyone!

Wanted: Xojo ‘Snow Leopard’ Release

Ever since Xojo adopted the Rapid Release Model (RRM) there have been critics. The critics said that it was leading to a perpetual state of beta software. I’ve always felt that the assessment was a little too harsh but I have definitely come around to that thinking.

In my many years of Xojo consulting I played the “what version of Xojo do I dare use for this client?” For a few years the Windows drawing issues meant that one of the early Xojo 2017 releases was my gold standard. And then finally Xojo 2019 R1.1 was my gold standard for all projects. I haven’t fully tested it but I’m really hoping (and frankly needing) that Xojo 2020 R1.1 eventually becomes my new gold standard.

The shear number of new things between 2019 R1.1 and 2020 R1.1 is staggering. People are still finding bugs in API 2.0 that haven’t been addressed. And yet Xojo is on their way to major updates to iOS and adding Android, adding Helpers and who knows what else.

Feedback is broken for intents and purposes. The top 20 list is all feature requests with the exception of two items that are most definitely bug reports. One is a Web 1.0 WebListbox issue that might as well be closed now and the other is a Xojo framework issue with ParseJSON and that might as well be closed now too with API 2.0 out. Everything else on that list would be freaking awesome, but only if the rest of Xojo was more stable and less buggy.

Monday a Feedback Report 61895 titled “Do a Xojo ‘Snow Leopard’ version that focuses solely on bug fixes and performance improvements. For those that don’t know the reference, Apple released a version of Mac OS X named Snow Leopard that did very little in the way of new features but worked on stability, speed, and bug fixes. It’s still considered one of the better OS’s that Apple ever made. I think in large part because they kept their promise of fixing stuff and not adding major new features.

Anyway, back to our Feedback Report. Within hours it had climbed to number 13 on the top 20 list and then was closed by Geoff as “Not Actionable’. This seems intentionally obtuse on his part because I know several long-term developers that have advocated for such a release for a long time. I even wrote about it in June of 2018 https://www.bkeeneybriefs.com/2018/06/xojo-and-the-rapid-release-model/. So this is not a new idea.

Look, I’m a developer, too. Working on bugs is no fun (especially for obscure ones) so I get, from a developers perspective, that new features are way more fun and exciting. But just once I’d love to get a Xojo that didn’t have a bunch of new classes, API, targets, etc. just so that the existing things we have becomes better, more stable, less error prone, and an IDE that is faster and more efficient.

Is this idea perfect? Oh heck no. I realize that bug fix releases might not attract new users. But it does make people like me happier and a happier Xojo developer is a good thing. I think marketing should be able to make hay with the sunshine that results from a better product.

Is that too much to ask?