RAD Still Means You Have to Learn the Language

Xojo is a great development tool that is a Rapid Application Development (RAD) environment.  That’s marketing speak for you can get stuff done quickly.  The marketing speak isn’t wrong but for many people they think this means that Xojo is ‘easy’ and the learning curve is next to nothing.  I hate to break it to those developers, but it just isn’t true.  Xojo, like any development language has a learning curve.  It might be a lot less than others but there is definitely one.

The truth is that Xojo is RAD once you learn how it works.  This means you have to learn the basics of the IDE, the language, and the debugger.  And only after understanding the basics of Xojo can you start taking advantage of the RAD part.

There are parts of Xojo that aren’t so RAD.  One of those, in my opinion, is database coding.  You still need to know SQL, and use the basic database classes to read and write data into your application.  In fact, it’s so low level that the IDE does not help you, in any way, which may lead to database errors.  The IDE will happily let you try to put a string into a numeric field in the database.  What worse is that depending upon which database is used (looking at you, SQLite) it won’t complain when you do so (thankfully this is not true of all databases).

Putting data into a database using the database classes is a two step process.  One, you have to query the database knowing what the field names and datatypes are as there is no autocomplete for them.  Xojo will happily let you (try at least) put a date value into an integer at design time.  It’s not until you try all this at runtime that things fall apart.  The same is true for updating and inserting data.  These are the reasons why we came up with ActiveRecord – our database classes for Xojo.

ActiveRecord is our way of making the Xojo compiler a little bit smarter.  It maps each table to a class and the properties in that class map to the database fields.  ActiveRecord checks to make sure that all of the fields in the table are represented in the class.  If not it flags the developer.  (It does way more but this post isn’t really about ActiveRecord.)

From our experience, jumping straight into ActiveRecord isn’t all that helpful for new Xojo users.  It’s a shortcut and you’re depending on our code without understanding it and I strongly discourage it until you’ve gone through the pain and tedium of using the standard Xojo classes.  In fact, when we train new developers we ALWAYS have them do a small project using the standard Xojo database classes.

Then we train them in how to use ActiveRecord.  The setup is a bit more involved and it’s not a perfect system, but once they start using the Table/Field autocomplete and having the compiler warn about mismatched datatypes they start to understand how much faster they can code database applications.  We are consultants, after all, and time is money.

Rapid Application Development systems do NOT mean quick to learn and being able to create an application with no experience.  RAD means that AFTER you’ve learned how it works it can be incredibly fast.  Once you learn Xojo is *can* be very fast to develop applications.

Anyone disagree with this?  What is the best method of learning Xojo?  Online documents?  Webinars?  Videos?

What is the Best Font for the Xojo Code Editor?

Somehow, after working with Xojo for seventeen years I’ve never changed the default typeface for the Code Editor.  It’s not that big a deal, really, but there are times when the default proportional font causes some issues.  At times it’s hard to read the difference between i’s, l’s, and 1’s as they all tend to blur together.  There are also some issues with selection and cursor placement that are annoying.

If I can find the right font I’ll change in a heartbeat.  What do you use and why?

Xojo 64-Bit Debugging

We’ve migrated a couple of projects to 64-bit and for the most part I’m pleased with how Xojo handles it.  It’s pretty seamless and it just works.  I can’t ask for anything more.  Additional observations:

The lack of Windows 64-bit debugging makes life difficult.  This appears to be corrected in 2018 R1 (in beta now) so that will be a most welcome change from having to go old-school and use logging to debug my Windows applications.  64-bit debugging in macOS and Linux works just like 32-bit applications.

There is no incremental compiling, yet, in Xojo.  This makes the debug cycle much longer than we’re used to with 32-bit applications.  When you debug a macOS or Linux application the dialog is quite clear that incremental compiling is off so there’s hope that the next step in this process is to get incremental compiling working.

The 2018 R1 beta cycle has taken a long time.  Presumably the level of effort to get the LLVM compiler working for Windows 64-bit debugging was painful.  And now that it appears to be solved hopefully all the other goodies on the plate (interops, Android, web 2.0) can all proceed at a good pace.

I had an instance the other day in 2017 R3 where Target64bit didn’t work.  After struggling with it for a while (because it should have worked) I deleted the plugin cache and restarted Xojo and voila!  It started working again.  I wish I had a better way of diagnosing stuff like this.


I’m a big fan of the Einhugur Treeview control for several reasons.  First, it’s very fast with the ability to LockDrawing.  Second, since nodes are persistent you don’t have to go to extra lengths to manage your nodes as the user expands and collapses nodes.  Load them once and they’re there for the duration.  It’s a good option, in my opinion, for really fast development work.

The only drawback I have with the TreeView control is that it’s not compatible with Gtk3 yet.  According to Bjorn it won’t be until this summer.  This means any Linux projects using it will have to stick with Xojo 2017 R1.1 until it’s updated.

Happy Coding!

Serial Devices as Keyboards – Yuck!

We’ve recently had a number of projects that required the use of a serial devices in desktop applications.  In all cases the clients said the devices are, “easy to use,”  since they act just like a keyboard.  If our experience is typical then I’d hazard a guess that many Xojo developers are frustrated with them.

Several projects required the use of barcode scanner.  Having a barcode scanner work as a keyboard makes sense, I guess.  It means that it can work with literally any application, anywhere, any time.  All it needs is focus on a text field and whatever the scanner sees it puts into the control.

In another project we had an ultrasonic sensor that would take the application out of idle mode and present the user with purchasing information.  Again, it acted just like a keyboard which means it works with any application as long as you had focus in a text field.

If you happen to know WHEN this information is going to come in it’s not so bad as you can plan for it.  Putting the focus in a field and waiting for information is easy.  It’s not so easy when that information could come at any time.  Of course all of our applications had data that could come in at any time and we had to be prepared to act on it immediately.

If you rely on a TextField or TextArea getting this information the rest of your interface can really suffer.  It means that when your barcode/sensor field loses focus you have to get it back (or you lose information).  Do you do this right away or wait a few seconds?  And if you have a complex user interface how do you deal with tabbing between controls, or even simple things like a user changing a checkbox because the focus is lost on your TextField?  It can be a nightmare to try and figure out and get right.  The differences between Mac and Windows and Linux can be frustrating!

The answer that we ended up implementing was putting the barcode readers into serial mode.  I’ve not run into a barcode scanner yet that couldn’t be used in serial mode.  Every scanner has a gazillion different modes and properties (all set via barcode of course) and one of them is to make it appear as a serial device to the computer.  On Windows this is a COM port and on the Macintosh they tend to show up as a USB Modem.  If I had to guess I’d say it’s harder getting barcode readers that are Mac and Linux compatible.

Once it’s in serial mode it’s almost trivial to create a class that monitors the serial port and reads the data WITHOUT needing the focus in a TextField.  The class then distributes the data to the objects that can consume the data.  What I do is have the window or objects register itself with the class and then when the data comes in the class sends it to all registered objects.  Each of the objects has an Interface with a simple HandleBarcode method.  This is known as the Observer Pattern and there’s an example that ships with Xojo.

My ultrasonic sensor wasn’t so easy to overcome as it couldn’t be put into serial mode.  However, it did come with a Windows-only SDK (thankfully it was a Windows only project) and with a little help with Declares we were able to get it working so we could tell if someone had walked up to the device and when they had walked away.  I’m not sure what we would have done if it had been a Mac or Linux project.

Serial Devices are relatively easy to work with in Xojo (as long as they show up in the serial list).  Having to deal with devices that act as keyboards not so much.  I’d highly recommend trying to get them to work as serial devices and save yourself a ton of grief.

What’s been your experience with serial devices in Xojo?

The Sound of Silence

Hey folks!  I just wanted to let everyone know that I’m still alive and kicking.  2018 has started off busy and chaotic.

I’ve been on-site with a client for nearly three weeks since the first of the year with a project, that while fun, has been challenging.  It involves big touch screens, credit card terminals, talking to three serial devices over USB, and calling into a Windows DLL.  This is the second major project with this client.  The first one required using Xojo for iOS with an integrated barcode scanner.

My son is a senior in high school (and all that entails) and co-captain of the FIRST robotics team.  I spent a good chunk of my limited free time writing their scouting application not only for desktop (Mac and Win) but for iOS as well (using Xojo of course).  Nothing like doing a big(ish) project for free.  Oh yeah, I’m nominally the programming mentor though I’ve had to step back some (since being out of town so much).

If you want to learn more about FIRST robotics and the challenge for 2018 go look at https://www.firstinspires.org/robotics/frc/game-and-season  I can’t say enough good things about FIRST and what it’s teaching these kids.  I believe the future is bright when I see what these kids accomplish (mostly) by themselves.  For what it’s worth my son received a really nice scholarship to a good university because of his FIRST robotics involvement.

To add into this mix BKeeney Software has been shorthanded for a variety of reasons.  My workload tripled a few weeks ago and we’re actively looking for a new Xojo developer.  As if I needed more things to do.  🙂

Mostly because of senior year commitments only one staff member is going to XDC in Denver.  This saddens me, a lot, since I haven’t missed an XDC since 2004 (I think).  It also means it’s unlikely that we’ll make it to the MBS conference in Munich this Fall.

I’m looking forward to some much needed time off.  I hoping that once things settle down and a new developer (or two) is on board I can get back to writing more.  2018 is going to be a big year for Xojo with so many things coming on board (the new web framework, interops, 64-bit debugging FINALLY working in Windows, and Android to name a few).

Coding Habits To Keep You Alive When Time Travel Is Invented

When you’re writing code we all know it’s a great idea to use method, property, class, and variable names that make sense.  It also makes sense to add in comments on code that isn’t clear.  But do you code in such a way that your future self won’t invent a time machine and come back and slap you in the face?  This is how you should be coding.  You really want your future self to appreciate the work your current self is doing.

One of the current projects I’m working on interfaces with multiple devices via serial communications.  Each one of them uses a different protocol (naturally) and some of the code was written by me and some of it by others.  Before I get into the Other Peoples Code (OPC) portion I’ll talk about my experiences with coming in cold to something called ccTalk.  ccTalk is a low speed communications protocol for use with Coin and Bill Accepters.

Had I ever heard of ccTalk?  Nope.  So the first thing I did was Google it.  I found a few helpful blog posts on it (saved the links) and found a few projects in Java and in C# and downloaded what I could.  I studied their code.  I found specification documents for ccTalk and device documentation and all were immediately added to the source code repository.  Why?  Because as soon as I move on to the next project I’ll forget the details.  If the information isn’t relevant in two weeks I’ll most likely forget about it.

In writing this post, I came to the conclusion that I also need to add any required drivers to the repository as well.  From experience I’ll inevitably need them in the field and if I don’t have them on hand I’ll waste time searching for them again.  Were they sent in an email, on the packing CD, or available from the website?  If it’s in the repository I won’t have to worry about it!

In my source code I document the message numbers I’m sending to the device and putting relevant details on the response and what I’m expecting back.  For ccTalk this might be a simple acknowledgement/busy response and depending on the command some additional data.  How much data am I expecting?  Did I get less?   Did I get more?  Does the checksum match my own calculation?  Do I have a way to create a log of the communication stream and is that log in human readable form or in hex?

This might seem like overkill but I’ve had to go back to my own code years later and relearn what I did.  This has involved finding the manuals again and trust me that’s no fun.  I think it best to assume you will not be the programmer on this project in the future.  Perhaps you get hit by a bus tomorrow and your client has to find a new developer.

The OPC portion of this project is using a different serial port to a different device and has exactly 24 comments in it.  Most of the comments don’t help me.  Commenting ‘If Serial1.open then’ doesn’t help me.  There are a few ‘Return //Exit this Routine’ comments that again would be more helpful if I knew why I have to exit the routine because it’s not immediately obvious from the rest of the code.  There are no comments regarding expected data.  No defensive coding techniques to ensure that if something is missing or garbled it can handle it gracefully instead of just crashing.  Of course there was no documentation for the hardware either so I’m not even entire sure I have the darn thing hooked up properly – all I can do is assume that I did until I get that documentation.  All-in-all I want to jump through the screen and scream at the other developer to a) put in useful comments; b) include the documentation with the source code; and c) include drivers and utilities that a newbie would need!

I try to make sure, in my code, that the developer that looks at my code in six months doesn’t curse me.  I say enough bad things about myself as it is.

What sorts of things do you do to ensure future you doesn’t curse your current self?

Xojo 2017 R3

Xojo 2017 Release 3 is now available.  As with all Xojo releases there is a mix of new features, big and little changes, and a host of bug fixes.  I’ll highlight some of the big items.  See the release notes for the complete list.

Perhaps the biggest change in Release 3 is that this is the first release where the IDE itself is 64-bit.  For macOS this is the only option.  In Windows the installer will choose the proper version for you system.  For Linux, the IDE is only 64-bit and will not run on 32-bit systems (note that it can still created 32-bit executables).

This is a major milestone for the Xojo IDE and is the culmination of many years of hard work by the developers.  It’s hard to imagine the work involved in taking a large product, like the Xojo IDE, that once assumed everything was going to be 32-bit only and rewrite practically every class, method, and function to ensure it works properly in 32-bit and 64-bit on Mac, Windows, and Linux.

So what is the deal with 64-bit? It lets the IDE use a lot more RAM.  In Windows especially this has been a limitation.  Some processes in the IDE, and in our built applications might be faster (emphasis on the might).  And since most computers are shipping as 64-bit these days it seems archaic to keep using 32-bit applications and in some cases for Linux it’s really hard to run 32-bit apps on a 64-bit machine.

One thing that changed because of the move to 64-bit is that the IDE Auto Saves the project before a debug run in a different way from previous versions.  Prior to R3 it used memory blocks to save this data in temporary files in case the IDE crashed.  In R3 it still saves but it’s using a much slower method.  It’s a long and drawn out explanation but it’s because of memory fragmentation that can happen even in 64-bit builds.  On very large projects this can take a LONG time and can make the IDE look like its stuck since there is no visual feedback of what it’s doing.

If this is a problem for you there is a way to get the IDE to NOT AutoSave the project before the Debug Run.  Warning:  This is for advanced users that understand the implications of doing this:

Confirm that Xojo is closed. You can set ‘Autosave Allowed’ to false the following ways:


Edit the Xojo Preferences ( ~/Library/Preferences/com.xojo.xojo)

Add a key with either a true or false value

<key>Autosave Allowed</key>



Use the same key entry style as macOS inserted in ~/.Xojo.Xojo


Use regedit to edit HKEY_CURRENT_USER\Software\Xojo\Xojo

Add a new DWORD value with the name “Autosave Allowed”

a value of 0 is false

a value of 1 is true

Another issue for 64-bit builds is the Currency data type.  According to long time Xojo developer Kem Tekinay using Currency is not recommended in 64-bit builds due to comparison issues.

The IDE now cleans up properly after a debug run.  This should eliminate the issue with the IDE showing a file IO error when trying to do multiple debug runs.

Layout Editor

Dragging IDE windows around with thousands of controls on the layout renders better now.  It is still recommended that you use container controls to limit the number of controls on each window.

Report Editor

Fonts on reports, especially in 64-bit builds, are now rendering at the proper size.  The Report Editor now honors locks as it should.

Code Editor

The Code Editor now highlights the lines of code blocks.  I’ll be honest, this is a totally unnecessary bit of fluff in the code editor but after using it for a few weeks I find that I like it.

The Automatic Code Reformatting now takes effect when you click away from the line of code.

Remote Debugger

The Remote Debugger Stub was rebuilt using 2017 R2.1 and thus has a speed boost.

The Mac Remote Debugger is now 64-bit and can run 32-bit applications as well.

64-bit and ARM Console debugger stub’s are included.


Lingua now has a scripting folder where you can run XojoScript to manipulate the translated text.  This is really useful in post-processing where if your translator puts quotes around everything, or likes to put the source and translated text together.  Presumably an enterprising developer could use XojoScript to connect to a translation service.


XojoScript now works on Linux ARM builds.


64-bit Widows apps now display manifest settings in the advanced tab of Windows build settings.  This allows you to set Windows versions and privileges for your app.


Support for iOS 8 and iOS 9 has been dropped.

Xcode 9 is now supported as well as 64-bit debugging.


Internet Explorer 10 support has been deprecated.

A number of bugs in the Web framework have been fixed.

Conclusions and Opinions

All-in-all, this release is an important one since the road to 64-bit has been a long and arduous process.  Xojo Inc. has missed on a number of promised deadlines this year and while some of them were under their control – many were not.  Let’s hope that 2018 is much kinder to their schedule.

I would expect the slow Auto-Save that popped up with the 64-bit IDE to be addressed at some point.  One personal opinion on this that irks me is their temporary fix for ‘advanced’ users.  Come on.  Really?  Stop treating us like children.  I don’t know about you, but in my 16 years of using Xojo I’ve only tried to use the AutoSave feature a handful of times and I can only think of one case where it actually saved me any time.  Keep in mind that you might very well never experience the issue if your project is small but I tend to have big projects and it’s a noticeable lag.

I did not like code block highlighting in its debut.  I felt that it was a complete waste of programming time.  After using for a few weeks it’s not that bad but I’m not sure it’s all that useful either.  I suppose if you have have six or seven layers if nested code it can be helpful but I tend NOT to do that.  It also might be really helpful with really long methods, and again, I tend not to do more than a page of code (I hate scrolling).

As with all Xojo releases it’s important to test your projects to ensure everything works as you expect.  I would expect a few things to shake out of the 64-bit IDE as more developers bang on it.  Xojo is a big project and the beta testers (myself included) can’t hit every single feature.  I’m not sure if I’d expect a dot release from R3 but I also wouldn’t bet against it.

Give me your thoughts!  Do you like R3?  Is it stable and reliable?

What Developer Components/Utilities Do We Need?

BKeeney Software has been doing Xojo development for a long time.  Our clients span continents and industries and when we’ve needed something that doesn’t already exist we’ve created it.  This is how ActiveRecord/ARGen and Shorts came into existence.  In both of those cases we used them internally for quite a while before making them available for others.  Some products, like Formatted Text Control, were purchased when the developer left the community and since we depended on the product we decided to keep up development on it.

The question of the day is this:  What components does the Xojo developer community really need/want that we don’t have yet?

To me, the clear winner is a nice grid component.  At one point I recommended the Einhugur StyleGrid and DataGrid controls but it was never updated for HiDPI and there are no plans to do so.  As far as I know there aren’t really any good replacements for them.  Add any suggestions to the comments below.

We use a ton of plugins but it makes no sense to have every plugin installed for every project.  We also don’t update plugins unless we have a need so a minor update to a three year old application probably doesn’t need the latest plugin.  Managing plugins across vendors is a real pain.  Likewise managing Xojo versions for client projects is a chore because one project might be on Xojo 2015 R4.1 for some technical reason while another is at a newer version (but not the latest) and some projects are on the 2017 R2.1. While it’s not hard to manage all this it’s harder managing that across multiple developers. I’d love to have a utility to manage Xojo and its plugins by project.  As far as I know there’s nothing out there that does all of this.  Do I need to write this myself?  And really, how many developers need this level of Xojo/plugin management?

What else do you need/want to make your Xojo development life easier?

Xojo.Core.Date Revisited

Geoff Perlman wrote a blog post https://blog.xojo.com/2017/11/04/get-better-dates-with-the-new-xojo-framework/ on how the new Xojo.Core.Date gives you a better date.  Better in that it does a superior job of handling timezones.

I will concede the point that the new Xojo Date class is better at timezones.  Timezones are icky and there are various areas of the world where they observe only partial increments of timezones.  The existing, global framework simply can’t handle those geographical timezones properly.  In addition to that, the global framework can get it wrong.  So the new framework is inherently better with timezones:  got it.

Where Geoff’s blog post goes sour, in my opinion, is when he talks about how the new Xojo Date and DateInterval classes cause more code but then goes on to show how it can made shorter.  I think his shortened example is indicative of the overall problem with new framework.

He starts with this example (note I am not implementing the Using keyword on purpose):

Dim d As New Xojo.Core.Date (2017, 11, 5, Xojo.Core.TimeZone.Current)

Dim di As New Xojo.Core.DateInterval

di.Hours = 3

d = d + di


The results is a message dialog displaying:  2017-11-05 02:00:00.  This is what the old Date.SQLDateTime method returned and what many developers need for database SQL operations.

He then goes on to show that this code can be reduced to:

Dim d As New Date (2017,11,5,TimeZone.Current)

Dim di As New DateInterval(0, 0, 0, 3)

d = d + di


Sure, it’s reduced, but now we’re passing parameters into the DateInterval constructor that we have to just know what they are.  Granted, it’s not hard to figure it out but when I’m reading code I don’t want to have to ‘figure it out’.  Whereas the first example was pretty explicit (add three hours) now I have to parse the number of parameters to figure out it’s three hours and not three days or three months or three seconds.  If when writing code I accidentally leave out a 0 it wouldn’t be immediately obvious that I’m not adding three hours but three days.  Ambiguity is never a good thing and I can’t tell you how many errors I’ve found in methods that have multiple parameters with default values because someone (usually me) missed a parameter.

I’d also argue that the documentation for Xojo.Core.Date is using, at worst, wrong example code or, at best incomplete documentation.  Using the variations of ToText results in some counterintuitive results.  If you use Xojo.core.Locale.Current (as all of the Xojo examples do), you get results based on YOUR system settings.  Really what you should be using is Xojo.core.Locale.Raw.  Below is a table that shows the differences for the following line of code when run on my macOS machine:

Dim s1 As String = d.ToText(Xojo.core.Locale.X, Xojo.core.Date.FormatStyles.Full, Xojo.core.Date.FormatStyles.None)

X = Xojo.core.Locale.CurrentXojo.core.Date.FormatStyles.Full 2017-11-05
Xojo.Core.Locale.Current Results
Format Result
Xojo.core.Date.FormatStyles.Long Sunday, November 5, 2017
Xojo.core.Date.FormatStyles.Medium Nov 5, 2017
Xojo.core.Date.FormatStyles.Short 11/5/2017
Xojo.Core.Locale.Raw Results
Format Result
Xojo.core.Date.FormatStyles.Long 2017-11-05
Xojo.core.Date.FormatStyles.Medium 2017-11-05
Xojo.core.Date.FormatStyles.Short 2017-11-05
Xojo.core.Date.FormatStyles.None 2017-11-05

So given these results it’s impossible in the new framework to get just SQLDate as the FormatStyles.None is ignored.  <feedback://showreport?report_id=50242>  Until this fixed, to do this on your own you would have to split the Text on the space and use the first half of it.

The only reason why anyone should ever use Xojo.Core.Locale.Current is to display the date/time to a user.  Xojo.Core.Locale.Raw should be used for everything else.  The distinction between these variations is confusing even to experienced Xojo users so I can only imagine the frustration from newcomers.

Ultimately, the New Xojo framework is not very discoverable and this leads to frustration.  While writing this article, to figure out the parameters in the Xojo.Core.Date.ToText function, I had to look in the freaking documentation.  Yes, there is the tips area but it’s not very helpful while you’re typing.  To see what the tip is you have to stop and hover your mouse over the method.  And that only works if it’s not an overloaded method.

This leads to some users complaining that Xojo isn’t as much ‘fun’.  At first I pooh-poohed the idea but the more I think about it, it’s true.  The new Xojo framework is verbose and hard to discover and therefore not as much fun.  I work in this language every day and while calling it ‘fun’ might be a bit of a stretch I can tell you that using the new framework isn’t fun.  The two client iOS projects I’ve done in Xojo have been painful for a number of reasons and not being fun is a valid but minor point.  I don’t find the documentation to be nearly as easy to read and discover related topics, and frankly the new framework seems to make things harder than necessary.  Certainly there is a ‘this is the way I like it’ factor you’d get from someone with nearly twenty years using a language but I do feel that the new framework is needlessly nit-picky.

My first blog post https://www.bkeeneybriefs.com/2014/12/xojo-core-date/ on the Xojo.Core.Date class was in December of 2014.  It’s nearly three years later and we’re still dealing with bugs and idiosyncrasies and it’s not widely used despite clearly being ‘better’.  It’s no wonder why people don’t really want to use the new framework and I wonder if any parts of the IDE are using the new framework.

What are your thoughts on the Xojo framework?

Formatted Text Control 3.1.9

BKeeney Software has released version 3.1.9 of the Formatted Text Control, a canvas based word processing control for Xojo Mac OS X and Windows applications. The FTC is an alternative to the built-in TextArea control and allows for in-line graphics, hyperlinks, custom components, better RTF support and much more. The demo project has quite a few examples, including a Masked Text Field, XojoScript code editor example, Embedded FTC (in your own canvas), as well as the word processor with page view.

This is a maintenance release and is free for all version 3 users.  It fixes the following items:

– Fixed issue with view scale < 1.0 setting up the clipping page incorrectly (#3500)
– Fixed spelling replace on TestWindow (#3581)
– Fixed Mac text AutoComplete positioning (#3574)
– Fixed Tabstop Widths (#3500, #3576)
– Updated Linux declare for doubleClickTime to include GTK3 in newer Xojo versions (#3575)
– Fixed the Draw Control border on the right side (#3473)
– Added SpellCheck configuration testing to contextual menu on TestWindow
– Added SpellCheck configuration testing to App.Close event
– Fixed resources directory location for the the Spell Checker initialization
– Added more comments in code if plugins are missing

The Formatted Text Control costs $150 and is 100% unencrypted Xojo code. Version 3 and above requires the use of the Text Input Canvas plugin (included in package) to allow for proper text handling in Cocoa builds. Product page at https://www.bkeeney.com/formatted-text-control/