What About Bob?

A number of recent forum threads and blog posts have invoked my name.  I mostly didn’t respond to those individual posts and decided to write one big post.

I’m still in the community:  Sort of.  I took a full-time job just before the pandemic hit the US and I’m so thankful that I’m able to provide for my family in a stable and hopefully long-term position.  Xojo consulting wasn’t keeping me very active and that’s even after it was just me doing the Xojo consulting.  You can chalk this up to a variety of issues that all revolve around Xojo.

Consulting leads just don’t show up like they used to:  At the height of BKS we had 4 full-time developers and a DBA/Project manager.  That means we picked up at least two big projects a year and a ton of smaller filler projects.  Those just don’t show up any more.  Do cross-platform apps now use a different language?  Is it because of Xojo quality issues?  Is it because of bad press?  Is it because I expressed my displeasure with Xojo?  A global pandemic that greatly accelerated a looming recession? Sure.  All of the above probably.  But I know other consultants that are in the same boat though a select few have flourished during this period too.  So maybe it’s an ebb and flow thing.

The whole API 2 fiasco:  API 2 is of dubious quality for existing projects.  If you have a couple hundred thousands of lines of code in classic API code you simply do not have the time or resources to convert.  What’s worse, is that I have several Windows apps that crash (as in poof!  No crash log or catchable exception) in any version of Xojo that uses API 2.  This one thing keeps me using 2019 R1.1.  (Update, this was resolved in one app that used WebKit for the HTMLViewer renderer and is marked as fixed for 2020 R1.1).

If you want proof of this statement ask anyone at Xojo when the entire IDE is going to be converted to API 2.  That alone is a multi-year project and I don’t care what Geoff says – they are NOT eating their own dog food when it comes to API 2.  They decided that it wasn’t worth converting to API 2 for existing work.  That says volumes if you ask me.

More targets less engineers:  Xojo used to have only desktop targets which meant that everyone on the development team focused on desktop.  Since then they’ve lost/fired engineers and created more targets.  How much time and effort has gone into iOS, and now Android development?  You simply cannot tell me that they are adequately staffed to handle all of these targets.  Web has been a multi-year project as has Android.  In the meantime they touched every single class in Xojo for API 2.0 and given the results I’m not sure the platform as a whole is better for it.  As far as I know they have no *dedicated* compiler engineer and that seems to be an issue with 64-bit debugging.

Locking of threads and banning of users on the forums:  It’s their sandbox and their tools so they can do whatever they want with their forum.  But it sure seems like a lot of threads get locked (by non-Xojo employees!) and posts get deleted rather quickly.  Look, I get it, they want to present a consistent look to the world but the almost fanatical control of the forum feels…desperate. Banning of users should be the very last resort.

The comical stance that professional developers are not the core users of Xojo:  Xojo will deny this, of course, but I’ve been around for 20 years in this community.  I’ve seen a lot of developers come and go.  There’s the hey, this product is very cool phase.  Then there’s the now I’m going to do something hard with this tool phase.  Some get through it.  Many don’t.  With the many dealings with former Xojo users not once have I heard of Xojo contacting them on why they left.  

Hell, maybe the users that know Xojo the best are the hardest ones to please.  Maybe it *is* easier to find new buyers than to appease existing customers for renewals.  But it’s the existing users that are the best marketing tool of the company in my opinion.  How many times have I promoted Xojo over the past 20 years?  Many people accused me of working for Xojo and being a shill.

Trust is Earned:  One of the things that we, as developers, need is trust in our tool of choice.  For many developers that have been around a long time that trust was earned a decade ago.  The API 2 fiasco and the many new targets has eroded and downright sheared off the goodwill for many of Xojo’s most ardent supporters.  I don’t know how the company recovers from those hits without being brutally honest with users and themselves.  They simply cannot be everything to everybody.  With Swift getting ported to Windows and .NET Maui on the horizon, in addition to other tools that are making big strides in cross-platform development Xojo needs to be laser focused on quality releases or they might find themselves in the dustbin of history.  Earn back our trust and I think they’ll be rewarded.  Keep mucking around with the above issues and the future doesn’t look bright.  Again, in my opinion.

Where I’m at:  I’m still doing Xojo programming for a living.  I am not doing much consulting because I don’t desire to.  I’ve always tried to do the best for my clients and, frankly, Xojo is not living up to my expectations for my clients.  I think they’ve forgotten where they came from and what developers LOVED about the product.  I’m sure there are some people that find Xojo because of web apps or iOS but I can’t imagine it’s a lot of new users.  I could be wrong on that but I’ve wondered for many years who is Xojo’s audience.

My products, the ones I’m still selling, are getting minimal to no effort on my part simply because I’m not doing much consulting.  These products were things I used on a regular basis and with no consulting there’s no usage and no need to update.  I’m looking for homes for them because they deserve to have a developer that cares about them.  Some in the community have suggested open sourcing them and I can tell you right now there is no freaking way that’s going to happen.  No argument in the world is going to convince me otherwise so just stop sending me that recommendation.  I’m not asking for much (in my opinion) to get these products but perhaps that’s also indicative of how poor the Xojo 3rd party market is right now and an overall indicator of the health of Xojo.

I wish nothing but the best for Xojo.  This last year and half has soured my outlook to the point where I just can’t recommend it to anyone that’s serious about a commercial desktop applications.  I haven’t done a web project in well over a year and it’s been many years since I’ve done an iOS project in Xojo.  Without outstanding desktop support I’m left in limbo and wondering why the hell I keep renewing a license.

I know I’m not the only one with these thoughts and ideas.  Feel free to add comments below.  Please try to be respectful towards Xojo employees and each other.

Chasing Unicorns

I’ve been on the search, recently, for alternatives to Xojo.  I’ve done some basic research into Lazarus and RAD Studio and both came up short in a variety of ways that you can read about in past posts.  So what am I looking for in cross-platform development tool?  I’ll spend the rest of this post talking about some of my requirements.  

Desktop Targets

Most of our consulting work is macOS and Windows with the occasional Linux or Raspberry Pi project thrown in for good measure.  Whatever development tool I choose it needs to be able to build for Mac and Windows at a minimum and anything it can do with Linux is an added bonus.  Rarely do we get a project that is just Windows or just MacOS.  Being able to desktop and consoles apps is a must on each target platforms.  

Native Controls

Maybe it’s my Mac background but I’d like my controls to be as native as possible.  This means that when Apple, Microsoft, or Linux distribution changes their UI (again) the application will just work without requiring an update from the vendor.  I’ll be honest that this is a want-to-have option as even Xojo isn’t completely 100% native (Listbox I’m looking at you).  Accessibility is a big concern for some clients so I’m willing to forego native if it’s ‘close enough’ and works.

Mac IDE

I’m a Mac user so I’d like to stick to my platform of choice if I can.  This means that the IDE must have the features that I come to expect on the Mac (keyboard shortcuts, standard Mac text editor features, Finder integration, and so on).  Can I live with working in Windows?  Sure, but remember I’m searching for unicorns so it’s not my first choice.  Plus, having a Mac IDE is a good indication how good of a cross-platform development tool it is.  I find it laughable, really, that some companies create cross-platform applications but yet don’t have a Mac IDE.  Um…so do you *really* do Mac applications or is this a marketing checkbox?

RAD Environment

I’ve been doing Rapid Application Development using Xojo for nearly 20 years and while you could argue that parts of Xojo are not very RAD (database development I’m looking at you) it is very easy and simple to get simple applications developed in practically no time.  Just last week I was able to get a simple Mac/Win desktop application developed for a client in four hours and that included preferences, full menubar, a simple text editor, talking to a web API, all with code signing, notarization, and installers.  Some of that is experience and the kit that I’ve developed over twenty years but some of that is simply Xojo.  Xojo makes it easy to create a MenuBar and quickly create menu handlers at either the application or window level.  The integrated Layout Editor makes it easy to add events for the window and controls and automatically drops into the integrated Code Editor.  I really want the next development tool I choose to be as easy to use as Xojo so I can get work done quickly and efficiently.

As a bonus I’d like my IDE to have integrated git and/or subversion integration.  I’d also like built-in code signing and notarization if possible too.  I realize this last part might require some remote magic since only a Mac can code sign and notarize Mac applications.  Neither of these options are available in Xojo at this point and require command like voodoo or a third party utility.

Double-Clickable, Compiled Executables

I really need my apps to be double-clickable in the Finder and Windows Explorer and just run.  I should never have to start up an application with the command line nor should I have to have a runtime installed to run the application.  Xojo applications are packaged to run independently and on the Mac they are in a bundle and even in Windows and Linux they are self-contained builds not requiring anything special from the operating system (as in no runtime necessary).

Community Size and Friendliness

I’d like my new development community to large and friendly.  When I have those inevitable questions regarding my new language and IDE I want a lot of options and where the community isn’t full of jerks.  For all of its issues this is where Xojo really shines because it’s one of the most helpful and friendliest communities I’ve ever been part of.  I’ve seen the vitriol spewed in other communities when newbies ask a question that should probably be obvious.  Hey, mistakes happen, and what’s obvious to one person may not be obvious to another.

Consulting Community

I’ve spent the last two decades as a consultant so why would I stop now?  Whatever community I go to I’d like there to be a decent consulting community where an up and coming developer could make a name for themselves.  I have no problem becoming ‘certified’ (whatever that means) to get listed and to get prospective clients.

Large 3rd Party Ecosystem

One complaint I’ve had about Xojo over the years is the lack of 3rd party options for controls and libraries.  If you want reporting options, a better grid, PDF creation and viewing, database ORM options, and a whole host of other controls and libraries your options are extremely limited.  My new development tool should have a vibrant 3rd party community so I don’t have to reinvent the wheel in many projects.  I’m okay paying money for a quality controls and libraries but what I really want are options because each one is different.

Good Documentation and Examples

This seems pretty self explanatory.  The documentation should be sufficient to learn the language.  In an ideal world it would be fully fleshed out so you can get a feel for the gotchas.  As far as examples go they should just work without having to futz around fixing stuff.

Bonus Things

It can do web apps.

It can do iOS and Android mobile apps (with some of the same caveats above).

The company/community behind it has a roadmap and what they want the language and IDE to be in the long run.

A standards organization behind the language.

A large enough company behind it, or a large enough community, to ensure future new features and timely bug fixes.

The things that I’m NOT concerned (much) about

Pricing – if it works then the price is (almost) irrelevant.

Licensing – if the language, IDE, and controls and libraries let me create commercial applications then I don’t care if it’s an MIT, GPL, LGPL, or Commercial license.

So that’s my unicorn list.  If Xojo is not going to be my long-term development tool these are the things I’m looking for.  Is this an impossible list?  I don’t think so but as someone coming FROM Xojo these are the things I’m looking for.  I you have some suggestions, I’d like to hear them and please let me know what the tool does NOT have from my list above.  I know it’s highly subjective but I think it’s important to acknowledge the limitations of the language and tool you work with every day.  Like Xojo, no development tool is perfect.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

I’m Tired

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

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

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

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

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

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

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

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

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

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

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

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

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

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

MarkdownKit Review

Markdown is a popular text formatting syntax in use all over the web. Markdown was designed to be human readable in plain text, and formatting parsers are available for many different formats.

There are a few different parsers for Xojo, available in both add-on and plugin format. Garry Pettet provided MarkdownKit for us to look at and review. MarkdownKit is written entirely in Xojo code, is fully CommonMark compliant, and generates HTML.

MarkdownKit is implemented with both String and Text versions, and is designed for both Desktop and iOS projects. MarkdownKit is provided as full source code, and includes documentation as well as examples.

With everything provided, MarkdownKit is very easy to use. It really is as simple as one line. dim sHTML as String = MarkdownKit.ToHTML(SomeMarkdownString) The output can then be passed into an HTMLViewer and displayed. This can all be done so fast you get near live rendering.

The way MarkdownKit renders the input is impressive. A MarkdownKit document is parsed into a syntax tree so that an implementation of the rendering interface can walk the document. What we get from all that is a fast and accurate Markdown renderer. And wow is it fast. The demo application really illustrates the speed of MarkdownKit.

Overall MarkdownKit has proven to be speedy, well documented, easy to use, expandable, and CommonMark compliant. MarkdownKit is a great Markdown renderer written entirely in Xojo code. If you don’t yet have a Markdown renderer in your toolkit, MarkdownKit is a solid option.

More information about MarkdownKit, pricing, and the demo downloads are available at the MarkdownKit Webpage: https://garrypettet.com/xojo-addons/markdownkit

BKS Tab Control – Drag Rearrange Tabs!

Lenexa, KS (February 8th 2019) — BKS Tab Control update can now drag rearrange

BKeeney Software releases a minor update for BKS Tab Control enabling users to drag and drop to rearrange tabs. Developers can enable or disable this feature using a switch in the Xojo IDE. A new event, TabOrderChanged, is raised when the user performs a drag-rearrange.

The BKS Tab Control is a set of classes that offer developers a classic “tabs control” for Xojo Desktop applications. The Tab Control can attach to any RectControl or Window, and will maintain a relationship to this parent control if and when it changes size. Tabs can be displayed in one of four directions (North, South, East, West) and individually offer options like a close button, an icon, a background color, and can be disabled.

Other features:
  • Optional CloseBox can be positioned on the left of right
  • If the CloseBox is selected a CancelClose event is fired
  • Optional Icon can be positioned on the left or right
  • Each tab can be independently styled (colors, fonts, text decorations)
  • Each tab can be disabled
  • Tabs that overflow may be accessed with an overflow popup menu
  • Works in HiDPI, non-HiDPI, and dark modes

BKS Tab Control has been tested in macOS, Windows, and several varieties of Linux with Xojo 2018 R4 and back to Xojo 2017 R1. The control may work unchanged in older versions of Xojo.

BKS Tab Control is sold as unencrypted source code and costs $75 USD. Existing customers can download the update with the original link on their sales receipt. More information and a demo project are available at: https://www.bkeeney.com/allproducts/bks-tab-control/

Xojo 2018 Release 4

Xojo 2018 Release 4 hit the internet this week.  This relatively small (84 bug fixes, 21 changes, 5 new items, and 11 doc and example changes) update is a nice end of year release that may or may not satisfy your Xojo dreams.  Let’s get into the highlights.

Of the new items list the big one is the new URLConnection class.  The URLConnection class works with the HTTP 1.1+ protocol and works with http and https connections.  This is a replacement for the Xojo.Net.HTTPSocket and brings back one of the things many developers missed about the old HTTPSocket class – Synchronous communications – using the SendSync method.  

SendSync is a concession by Xojo with the caveat that the application may appear to freeze while running this method.  The regular, and probably the better, Send method is asynchronous and does not freeze the app.  Admittedly the async way is the better way but for many developers the synchronous method is easier to implement and ‘good enough’ for their use.  Still, consider using the async method.

The Screen class now has the ScaleFactor property.  There are two new global constants: AppSupportsDarkMode and AppSupportsHiDPI  that are pretty self explanatory.

iOS builds now use the iOS 12.1 SDK.  macOS builds now use the 10.14 SDK for 64-bit builds.

There are couple of changes that are noteworthy.  The first being that the Windows IDE can now successfully build large projects for Linux 64-bit and ARM targets (frankly I didn’t know this was a problem but I bet that ‘large’ is the key word).  Any remaining threads are now killed after the app.close event (possibly a reason why some apps in macOS crash after they quit?).  EnableMenuItems no longer fires needlessly on every keypress in Windows.  Lingua and Remote Debugger Stub have been updated to work with Dark Mode on macOS.

There are 84 bug fixes in this release.  The more important ones (at least in my opinion):  The Build folder is properly emptied between build runs.  Remote Debugging to a Raspberry Pi no longer randomly crashes when stopping at a breakpoint.  Browsers that have disconnected from the web app will now reload the web app so they don’t appear frozen.  There are also a couple dozen IDE bug fixes to the Inspector, Navigator, Find & Replace and a number of the editors.

As with any new release you need to thoroughly test your projects before doing a public release.  It was noted during the beta period that the Einhugur Search Control didn’t work properly in Mojave but has since been fixed.  We had one large project not work when remote debugging from Mac to Windows but I haven’t had time to track it down.  If you have found any new issues with R4 please submit a Feedback report right away!

Happy coding!

BKS Tab Control

Lenexa, KS (June 20th 2018) — BKeeney Software releases BKS Tab Control
The BKS Tab Control is a set of classes that offer developers a classic “tabs control” for Xojo Desktop applications. The Tab Control can attach to any RectControl or Window, and will maintain a relationship to this parent control if and when it changes size. Tabs can be displayed in one of four directions (North, South, East, West) and individually offer options like a close button, an icon, a background color, and can be disabled.
Other features:
— Optional CloseBox can be positioned on the left of right
— If the CloseBox is selected a CancelClose event is fired
— Optional Icon can be positioned on the left or right
— Each tab can have a different background color
— Each tab can be disabled
— Each tab text can be stylized with font, font color, text size, bold, italic, underline
— Tabs that overflow the available width may be accessed with an overflow popup menu
— Works in HiDPI and non-HiDPI modes
BKS Tab Control has been tested in macOS, Windows, and several varieties of Linux with Xojo 2018 R1.1 and back to Xojo 2017 R1.  The control may work, unchanged, in older versions of Xojo.
BKS Tab Control is sold as unencrypted source code and costs $75 USD.
More information and demo project download available at:
macOS
Windows
Linux
All Directions

Is Xojo the Right Development Tool

Quite often prospective clients, and developers thinking of learning Xojo, ask my opinion of Xojo.  They are about to embark on a journey spending tens of thousands of dollars on a cross-platform tool and they want to know if Xojo is a right for them.  It’s a good question and I’ll share some of what I share with them in no particular order.

Xojo is pronounced “Zo Jo”.  I can’t tell you how many times I’ve heard it pronounced “Ex Oh Jay Oh” or something else.  They just don’t know and I think it spooks a lot of people as it doesn’t exactly roll off the tongue.  Xojo has been around under various names (REALbasic and Real Studio) for twenty years – all with the same company.  At that point it’s easy to name a dozen languages/development environments that were popular twenty years ago that either don’t exist today or been sold so many times that they’re now obscure tools.

This isn’t your fathers BASIC.  Xojo uses the BASIC syntax but this isn’t like the venerable Visual Basic or even older GWBasic or QBasic.  Xojo apps are NOT interpreted at runtime – they compile down into native code for each of the platforms.  The language itself is a modern object-oriented language that happens to use the BASIC syntax.  Xojo is updated three to four times a year and has undergone a lot of upgrades in the past two decades.  It first supported 68000 code, then PowerPC and Fat applications, Carbon, and now finally Cocoa on the Mac side.  They’ve added Windows, Linux, Raspberry Pi (Linux ARM), desktop and console application targets.  In the mobile space they’ve added iOS, and by the end of the year Android.  They’re also in the middle of the transition from 32-bit only applications to 64-bit applications.  For the most part things ‘just work’ and developers don’t experience too many issues (bugs happen but think about how many targets they’re supporting!).

Xojo applications are self-contained.  Take a compiled Xojo application and (with very few exceptions) literally copy the files to another computer and the application will just work.  Even Windows applications don’t need an official installer, however, it is recommended since most Windows users are comfortable and familiar with using them.  Most Mac applications are installed via drag-and-drop from a disk image but an installer can be used on the Mac as well.  This ease-of-installation is huge and it’s rare to have “DLL Hell” issue since all required libraries and resources are bundled together.  This does make the resulting output larger than some other development tools that depend on system libraries but I’ve rarely seen this an issue.

Xojo provides nearly everything you need in one tool (with some caveats).  The Xojo IDE has Code, Form, Menubar, Database, and Report editors (to name some of the big ones) in one tool so you never have to use another tool.  We’ve found the database editor to not be powerful enough so we prefer external database editors.  The built-in reporting tool also isn’t very powerful so we created our own reporting tool (Shorts) which has served us well in our consulting projects.  The nice thing is that all of the built-in tools work seamlessly with each other so the tools that are powerful enough for you ‘just work’ with few hassles.  The editors try really hard to protect your from hurting yourself while other tools are just a big text file that must be in an exact format.

The Xojo community is incredibly helpful.  The Xojo Forums are filled with some of the most helpful people I’ve ever met.  Some of the Xojo engineers respond to questions, but usually the community answers before they get to it.  Many other support forums are rude and condescending to newcomers to their language/tool.  The Xojo forum has even been known to answer questions about other tools.

Xojo is a cross-platform tool and because of this it has some compromises.  Controls are often the lowest- common denominator.  Grids especially aren’t as powerful as some are used to in the Windows world.  This is mainly because complex grids are not common in Linux and Mac environments.  Other controls have similar issues.  Things like automatic spell checking in TextArea’s are platform specific as on the Mac.  At times it is disappointing that there aren’t more control options for Xojo right out of the box (think date and calendar controls) but thankfully there is a third-party market for controls and libraries for Xojo that can often help.  Even though much is provided for you, it’s possible for a developer to use OS API’s using Declares that can significantly modify the appearance and functionality for some applications.

Xojo is a Rapid Application Development (RAD) environment.  Between the all-in-one IDE and the language creating applications in Xojo is fast.  This means that an initial investment can get your app developed faster and cheaper than many other languages.  Obviously some of this depends on the developers doing the work but it can make a huge difference.  We’ve always told clients that if they’re not happy with Xojo performance after the initial release they can use our code as the proof of concept to the developer in whatever language they choose.  There have only been a handful of clients that have ever switched languages after release and that’s usually been switching from desktop apps to web app.

The cost of Xojo isn’t very high compared to some tools.  For $699 per year per developer you can create web, console, and desktop apps for Mac, Windows, Linux, and Linux ARM plus iOS apps.  That’s all in the same environment and same language and with the exception of iOS applications (which requires a Mac) you can use Mac, Windows, or Linux to create everything.  Many developers use third party controls and libraries and even those are relatively inexpensive.  Plus, there are no royalty fees for your Xojo made applications.  All-in-All it can be a relatively inexpensive tool.

What considerations have I missed?

The Xojo Community is Awesome

Have I told you how much I love the Xojo community?  I’ve been part of it for fifteen years and I’ve met hundreds of Xojo developers at developers conferences and probably exchanged emails with thousands more.  I am amazed at how much this community helps each other and I wish there was a way to promote that as a key feature of the product.  It’s a big deal.  Really!

If you’re just starting out using Xojo know that there are a bunch of people, myself included, that are willing to help out, if we can, on your journey.  Programming is hard.  Well, I don’t think it’s hard because I’ve been doing it for so long, but it is complex at times and that makes it hard.  Just ask your question in the Xojo forums and you’ll almost always get an answer within hours.

Even Xojo pros, such as myself, have need of help.  Xojo covers Mac, Windows, Linux desktop, console, and web apps.  It does iOS apps for iPhone and iPad.  It now does Raspberry Pi for heavens sake!  It works with dozens of different databases.  There is simply no way any one person is going to know everything there is to know about Xojo.  It just can’t happen.  So yes, I go to the forums, all the time, and ask for help.

Just the other day I asked for some help with WooCommerce.  Not Xojo related, really, but certainly related to a project we’re working on for a client.  Within a few hours I had half a dozen developers private message me saying they might be able to help.  Subsequent contact narrowed that list down a bit but the point is that I have probably shaved off several days worth of work simply by asking for advice.

I am biased towards Xojo, naturally, as it’s been my primary development language for fifteen years.  I think I’d be hard pressed to find such a friendly community.  I call many on the forums my friends even though I’ve never physically met them.  The few that I’ve met in person have lived up to their forum reputations and are really friends for life.

So maybe this is my belated Thanksgiving post.  I am thankful that so many years ago I jumped both feet first into the tool.  I asked questions – many of the silly and redundant.  I became more proficient and then made another jump to start blogging about it, making products for other developers, and training the next generation of developers.

So if you are in need of a cross-platform development tool I highly recommend Xojo.  It ain’t perfect but no development tool is.  If you jump in I think you’ll love the community.  I know I do.

What say you fellow Xojo developers?