ARGen Has a New Home with Tim Parnell

When you work on a product long enough and depend on it every day you grow attached to it.  It’s been years since I’ve done a normal Xojo database application because ActiveRecord makes things so much faster and safer.  The feedback we’ve received has almost been universally positive.

So when I decided to take a full-time position this spring I started shopping for a new home for ActiveRecord and ARGen because so many Xojo developers depend on it.  Today, I’m announcing that ARGen is now owned and maintained by Strawberry Software https://strawberrysw.com.  

This is great news for a variety of reasons.  First, Tim Parnell is an excellent developer and I know he’ll do an excellent job maintaining and improving the product.  He’s already shared with me some of things he plans on doing with ARGen and I’m looking forward to using it.  Second, Tim worked for BKeeney Software for years and was one of the developers that worked on ARGen so he’s intimately familiar with it already.  He’s used ARGen in consulting projects for us and is now a Xojo consultant on his own so you can be assured it will continue to be maintained and grow with Xojo.

What does this mean for ARGen users?  You’ll get an email from Strawberry Software in the next couple of days for a new download.  You’ll be able to use your existing license code and you’ll be on their license system.  Then wait for future updates.  With the updates I know about I think it will be worth the wait.

I want to thank everyone that was an ARGen user over the years.  It makes me happy that we were able to make a difference in many Xojo developers lives.

So go on over to Strawberry Software’s website and check out ARGen and Tim’s other fine pieces of software for Xojo developers.

Happy coding!

Xojo Design Mistakes Video

Xojo released my 2019 Xojo Developer Conference video on Xojo Design Mistakes on YouTube a few weeks ago at https://www.youtube.com/watch?v=s-FOUxAtK7I&feature=youtu.be.

I liked my alternate title better: Thankfully time travel hasn’t been invented otherwise my future self might come back to murder me because of stupid decisions.

Based on feedback many people found the video to be useful. Hopefully you do too.

The reason I brought this up today is that I’ve spent the last week working on optimizing several large Xojo projects. I’ve identified several areas to look at and if I think it’s it might be worthwhile to look at (after using Instruments and Profiling) I will create a small sample project proving if I can make it more efficient. There are several things that I believed to be true that are not. Here is my initial list:

NthField is Slow: It’s not fast and I wouldn’t recommend using it in a huge loop but it’s not *that* bad. Converting a project that uses it a lot to use Split and then bounds checking just isn’t worth the overhead and hassle of screwing up the code. Plus, it’s one-based whereas Split creates a zero-based array.

String Concatenation is Slow: Again, it’s not exactly speedy in loops but we’re talking ticks if the strings are relatively short. If you use something like this:

dim someString as string = "First line " + _
" second line" + _
" third line"


it is way faster than:
dim someString as string = "First line "
someString = someString + " second line"
someString = someString + " third line"

MBS Functions are always faster: Sometimes MBS *is* faster but not always. Things like picture saving is actually pretty efficient in Xojo. Directory scanning *is* faster using MBS but only in classic API. If you’re using API 2.0 use the FolderItem iterator in a directory and it’s as fast as FileListMBS.

Anyway, that’s a quick and dirty summary of things I’ve learned. Some times it’s good to challenge your assumptions. Happy coding!

AutoComplete Wish

I understand that the future of Xojo is API 2.0.  I have used API 2.0 and while I disagree with some of the naming conventions I can live with it.  I do have a problem with many of my older projects, however.  My older projects, especially the big ones, will most likely never use API 2.0 because it’s simply too big of a task to convert.

To upgrade to API 2.0 for a desktop project I have to change my error handling to go from checking for error codes to handling exceptions.  Any string manipulation cannot simply be upgraded because the older API is 1-based and the newer one is 0-based.  And the sheer number of property name changes is disastrous in some projects.  Converting from Date to DateTime is not a simple replacement either.

That’s not to say that these things are not doable but they are not desirable right now.  And I’d really like to not accidentally invoke an API 2.0 method or property because AutoComplete shows me both.  AutoComplete conveniently shows me the old, classic property/method in red which is great but I have no way of knowing what is new for API 2.0.  Therefor I’d love to have the option to choose what is shown in AutoComplete.

Feedback 57885 Feedback #57885 is just that.  This case is currently ranked fairly high so I’m not the only one that thinks this is a great idea.  The basic gist of it is this:  there is a preference setting that allows me to select what I see in AutoComplete, API 2.0, API 2.0 and Classic, or just Classic API.

In the ideal world (as stated in the Feedback case) this would change the deprecation warnings for API 2.0 if you’ve selected Classic API and it would also switch the local documentation to the proper usage to avoid confusion.

Obviously, Xojo does NOT want to implement this because API 2.0 is the future of the platform.  My argument is that without this mechanism many of us with older, big projects, won’t update our licenses because we can’t/won’t use Xojo with API 2.0.  

This is not a good situation to be in because I feel we’re one macOS upgrade away from disaster.  If you’ll recall before Catalina was released FolderItems were broken in  for a while.  This turned out to be an Apple bug that was fixed.  Another example is the ColorPicker and if you’re using an older version of Xojo you have issues with it that you have to workaround.  What happens with Son of Catalina comes out and something else is deprecated and we *have to* upgrade to newer Xojo.

You might feel like I’m complaining for the sake of complaining.  I assure you I am just looking out for my clients assets and my own hard work.  I can’t justify the cost and expense to upgrade to API 2.0 and I really don’t want to mix and match API’s.  I could use a newer version of Xojo but I just can’t take the chance of using something (API 2.0) that’s not fully proven (to me) yet.  All it takes is one mistake and I have a mad client.

Currently 57885 is ranked 9th.  If you’d like to see it get implement throw your points at it.  What do you think?  Am I agonizing over AutoComplete too much or do you think I’m justified in my concern and request?

May We Live in Interesting Times

I’ve been a Xojo consultant for nearly 20 years.  BKeeney Software has worked on dozens of commercial applications and untold numbers of private projects during that time period.  Consulting is both an extremely rewarding and terrifying business since income can be so variable.  We’ve had multiple employees for years and providing health insurance costs is an expense that’s ever growing.  Having your own business is hard in the best of times.

Over the past twelve months we’ve had two employees leave on their own volition to pursue other employment opportunities.  During that same period the amount of new projects slowed to a trickle and even existing clients haven’t brought in as much new work as they have in the past.  Where once we routinely acquired new projects it just didn’t happen as much in 2019.

Consulting is a weird business where every client wants their project done last week for as little money as possible and then get yelled at when you tell them version 2 is going to cost a lot more money.  As a consultant I’ve had to compromise with what’s best for a project with what the client is wiling to pay for.  It’s a constant struggle and one that I can’t imagine going away as a consultant.  

Earlier this year I was presented with the opportunity to take a full-time job as a senior developer for a company that uses Xojo along with other programming technologies.  I have accepted that position and started with them in a full-time capacity a few weeks ago.

BKeeney Software will continue to support existing clients to the best of our ability.  We will not be taking on new clients and we will have to be very selective in taking on additional work.  We hope the transition is as painless as possible.  When we cannot do the work we will give clients a list of Xojo consultants to contact and we will coordinate with them as best we can. If you’d like to be on that list let me know. Send me an email with your qualifications, types of projects that are in your wheelhouse, and maybe even a client reference I can contact.

Several Xojo developers that know me socially (and knew about the new job) have asked about our products, mainly ARGen, Shorts, and Formatted Text Control.  At this point in time we will continue to offer support just like we always have.  However, we are hoping to find new homes for them and have already reached out to various developers that we feel will treat them and our existing customers right.  Our products were mostly driven by consulting and if we are not consulting we have no need for the products.  Since we know a lot of developers use these products we’d love for them to stay in the community and stay actively developed.  If you are interested in acquiring the rights to any of the products, please contact us.  

I love the Xojo community and its users.  I’ve never found a community that is as passionate about a product as the readers of this blog.  I’m not leaving the community – but transitioning into another form.  My new job uses Xojo. It’s a very large project and is certainly bigger than anything I’ve ever worked on before.

I’m looking forward to working on a set of products with a team of dedicated developers that are working on products that matter while providing a stable work environment for my family.  Certainly the events currently happening in the world do not make consulting any more stable so the timing of this opportunity was exceptionally favorable.

I still plan on doing some blogging about Xojo but it will certainly slow down.  As Web 2.0 and Android hits I will kick the tires and give my opinions of them because…well…I always have an opinion.  🙂

Stay safe and I look forward to seeing you all again at a Xojo event! Happy Xojo coding!

Xojo.Connect Virtual Keynote

Xojo released a video today of Geoff Perlman talking about Xojo.  This is mostly information that would have been given at the Xojo.Connect keynote address but, well, we all know that it isn’t normal times.  I urge you to watch the video and come back.  I won’t bore you with repeating what Geoff said but I’ll give some thoughts on each section.

Last 12 Months:  Pretty typical recap of the last year.

In The Works – Big New Features:

Xojo Cloud:  Makes sense to go to all 64-bit and to make them stand-alone apps.  Having the built-in load balancer is really nice for those that don’t want to mess with it themselves.

Feedback:  Web based.  Yay!  It’s about freaking time to get away from the stupid desktop app.  I guess my question is will it improve the responsiveness of Xojo actually fixing bugs that are reported?

Web 2.0:  Telling me you have great looking controls and not showing me anything to prove that makes me doubt the claim.  Session restoring should be a nice feature assuming it works as required.  

Really, you want to add 10,000 rows to a ListBox?  I’d say that’s a bad example as that much data should be ‘paged’ but whatever. Users will do stupid stuff like that all the time.

What they didn’t say was that the conversion to Web 2.0 is a one-way trip.  Make sure you backup your project before you do that.

iOS:  Notifications, SearchField, Application Shortcut Items, Custom URL Schemas are all basic features and should have been in the product long ago.

iOS plugins will be good news for MonkeyBread and maybe one or two others.  No idea if this means the plugins are still C++?  I’d assume so but no details given.

Having String and Variant instead of Text and Auto is a good change.  Mobile classes to replace iOS makes sense with Android sometime in the future. No timeframe makes it hard to guesstimate how excited anyone should be.

API 2.0:  While it’s cool that a desktop, web, iOS, and Android projects can now use the exact same code it’s a shame that we can’t have all of those projects from a single project with different targets.  I know I’m being petty but that seems like the next logical step.

Desktop Controls will be replaced to use the API 2.0 events.  This is the way it should have been done from the beginning.  It completely eliminates the train wreck that we all experienced with the now non-existent Xojo 2019 R3 release.

Android:  The fact there’s an Android version of the Conference app in Google Play Store is a good sign that it’s coming along and fairly well advanced.  Hard to say exactly how far along but is but still.  The Android video should be interesting.

Graphics:  Having XojoScript be able to do graphics is a really nice feature.  I’d love to know what the refresh rate can be.  I don’t have any idea on what I’d use it for, but I could see that being used to create control plugins made in Xojo.

PDFDocument:  It’s a great beginning.  I suspect that most people will be disappointed because it looks like it’s graphics only.  Meaning that the PDF can’t be searched.  I might be wrong but that will be the first thing that I’ll check.  Without that it’s pretty minimal feature set and not what many people want.

Worker Class:  A good discussion on why threads are hard and why using console helper apps makes use of multiple cores whereas a normal thread only uses one.  Geoff might be using App.DoEvents in the only permissible place to use it but even then, I wouldn’t use it since too many people use it as a crutch and abuse it.

The Worker class looks really cool and is probably the best thing that Geoff discussed.  I have many questions on how the class and its events work.  For example the JobRequested and JobRun events only uses string.  Is that the only datatype we can use with that?  I suspect it is because it’s creating a console app in the background.  Regardless, it really takes the work out of working with console helper apps.

Also no talk about what’s the preparation time. Would it be easier, in the long run to simply create your own helper console apps? My guess is probably but the details are important here.

Overall:  It’s nice to see progress on things in the Xojo universe and a few surprising additions (Worker class).  What we don’t know is when these things are going to ship (and be useable).  The thing I could use today is the Worker class and I suspect that it will be the last thing introduced (sorry for being pessimistic).  This has always been the most frustrating thing about going to XDC and being told about something really cool and then having to wait a year (or more) before we see it.

Training Site is Cancelled

It is with great sadness that I’ve finally killed our Real Studio/Xojo training web app. Ever since API 2.0 came out, and the upcoming changes to Web, iOS, and eventually Android the training app was breathing on fumes. It was increasingly obsolete and out of date. Late last year I purposely disabled anyone from creating a new subscription and no one complained. So today it was deleted and my Xojo Cloud account cancelled.

The training site was originally in Joomla and it was a major pain to administer and use. That’s mainly because of Joomla but it served its purpose – as it proved that there was a market for the training videos (albeit a small one). When Xojo for Web came out I figured it was a good fit for me and great way to learn (I remember sitting in the flat in Nigeria working on it) and I learned a lot about Xojo web apps (the good, the bad, the ugly).

At its height there were over 200 videos covering everything from the Editors in Real Studio and Xojo, to many of the major classes, most of the controls, desktop, web, and iOS applications. I even had two start-to-finish desktop application and one start-to-finish web application projects. Most of the videos came with a project file with code for people to download and use. Over 11,000 hours of video had been streamed from my Xojo web apps including a large chunk of it on Xojo Cloud. That’s not nothing.

Some people have asked why I just didn’t update them for modern Xojo. The answer is time. For every minute of video there is at least ten minutes off-screen work between creating the project and editing the recording so that viewers didn’t see the twenty minutes of me trying to figure out why there was an error in code or hear the um’s and ah’s while I was talking. Add in the fact that Xojo changes every three months and it would be a never ending project. As it is it’s been over a year since I’ve added new videos and I don’t miss it as it’s a lot of work.

The training videos were never popular enough to pay for my time but I’m glad I did them as I learned a lot doing them. One thing I learned is that people new to Xojo liked it when I made mistakes. Early on I was worried that people would be mad if the videos weren’t perfect. Instead they learned how to debug watching me figure out what was wrong and that’s something that’s very hard to do via printed material.

Early on I also learned that I used a LOT of filler words. So I joined Toastmasters and learned to enjoy the silence between thoughts. I started doing less talking while typing during the videos and this led to faster typing (or rather sped up video while typing) and then better explanation of what I had just typed. Really, record yourself someday to hear what your fillers words are. 🙂

I answered a thread on the Xojo forums a while back on why isn’t there any training videos on a site like Udemy. The answer, again, is time and money. Just for grins I started doing an outline of what I thought a really good class on Xojo would be and I stopped when I got to a hundred topics. That’s one hundred videos that would be on average of 15 minutes each (some shorter and longer obviously) and given the math above it would be a full-time job with little gain. Xojo is, after all, a small market and it changes so rapidly that it would always be in need of updating.

If you were one of the subscribers, I thank you from the bottom of my heart. It was my pleasure creating something you hopefully learned from.

Until we meet again. Happy Xojo coding!

API 2 Bit Me This Week And I Wasn’t Even Using It

I had one of those weeks where my nearly 20 years of Xojo knowledge went up in smoke.  I started a new project and was using the classic API.  I did this because it was a database application and I’m not convinced that the major database changes with API 2.0 are tried, true, tested, and worthy of every day usage.

I was testing to see if a string was contained in another string and did this:

Dim bDoesNotHave As Boolean = sString1.InStr(kSomeConstant) = -1

Gosh, where do I even begin to explain the hot mess this is?  First, InStr (classic API) returns a zero if sString1 doesn’t contain the string kSomeConstant.  Second, the API 2.0 replacement is String.IndexOf but that does return -1 if the string isn’t there.

Thankfully, testing discovered that the code wasn’t working but I felt pretty dumb.  This is one of those areas where I think API 2.0 is totally going to mess old timers like me up.  I’ve used Instr for nearly 20 years and all of a sudden my brain tells me, oh, no, this returns -1 if the string isn’t there.  True – only if you’re using API 2 and I was not.  Which is so weird because I’ve not created ANY new projects in API 2 – just some random testing.

I’m mad at myself for not remembering and mad at Xojo for changing the rules.

Xojo Web 2.0 with New API 2.0 Event Names

Xojo is usually pretty tight-lipped about future releases with good reason.  We, as users, usually hold them to features that they mention (even when they throw out the usual disclaimers about things might change) so it’s pretty unusual for them to offer any information on future releases.  In the past month or so there has been information leaking out through the forum that says that Web 2.0 is in the later stages of development and they are pretty confident on the feature set.

We already know that Web 2.0 is using API 2.0.  One thing we did not know until recently is that Web 2.0 is going to use the ill-fated new event names that so upset the community in the 2019 R2 release.  We don’t know exactly what the events are going to be in Web 2.0 but we can safely assume the standard Open and Close events are now going to be Opening and Closing.  I (naturally) have several thoughts about this.

First, I think the event name changes are needless.  Opening is not more clear than Open.  Closing is not more clear than Close.  I think the new names are as meaningless as the originals.  So I think using the new events names is a complete waste of time.  Instead of the twenty plus years of institutional memory we all have with event names, not to mention documentation and example code we have to learn new event names.

It won’t matter for Web 2.0.  Probably.  I say probably because we don’t know for sure but the hint is that ALL of the Web 2.0 classes and controls will have new names and thus not affect the 3rd party market as much (although we can presume that anyone selling 3rd party controls for Xojo web has a big task in front of them updating them for Web 2.0).  Does this class name change extend to WebApplication and WebSession too?  Only time will tell.

Another reason why it might not matter is that subclassing controls in Xojo web apps was hard.  Maybe non-existent?  Regardless in our really big web projects we NEVER subclassed web controls.

If indeed every control in Web 2.0 is using a new name it eliminates much of the griping that we had with Xojo 2019 R2 because there is no existing market.  It’s all new there are no naming conflicts.

Since events are added via dialog in the IDE most users will probably just roll with the changes.  Since converting any Web project is a one-way process most users project won’t notice it.  There’s still the possibility of Raising a non-existent event I suppose but I suspect that’s a more advanced feature many Xojo users don’t use and presumably the compiler will give a useful error message.

If the new event names are indeed the future it makes zero sense to have part of the product use Open and another part using Opening.  So this means there are going to be new controls (presumably for desktop and mobile at some point) that have new unique names and therefore use the new event names.  Again, same situation since if they have new control/class names there is no issue with conflicts.  This is similar to moving from the old HTTPSocket to URLConnection with similar functionality but slightly different events.

This last point is the most important one.  If Xojo hadn’t foisted the new events names in the old classes to begin with we wouldn’t be where we are at today.  I still think the new event names offer zero clarity from the old names, but whatever.  I’m just a user, don’t work for the company, and I’m not an MVP so my opinion doesn’t matter.

Okay, Xojo users.  What are your thoughts on using the new event names in Web 2.0?

One last random thought:  Because Web 2.0 sessions have been added at the Xojo Developer Conference (a.k.a. Xojo.Connect) I’m guessing that it will be released as a beta during the conference to attendees.  I am not planning on attending so you’ll have to get your news elsewhere.  This will be the first conference I’ve not attended since 2004 or so.  Hope everyone has fun and gets a lot of useful information out of it.

Xojo 2019 Release 3.1

Last week Xojo 2019 Release 3.1 hit the internet.  This small bug fix release is a critical update and is recommended if you are using one of several areas.  Let’s get into the details.

One of my biggest issues of concern with API 2.0 is with a dangerous memory leak in the DatabaseRow class.  Doing practically anything with a database would quickly eat of RAM until it brought your machine to its knees.  R3.1 fixes this issue and also a memory leak when using ODBC.

A couple of iOS bug were fixed in this release.  R3.1 fixes a regression that caused iOSTextAreas to overflow their bounds when the border was set to None or Regular.  iOSView headers no longer show the previous view during the PushTo animation.  Xojo added the Operator_Compare to the ColorGroup so that it can be compared against a color value.

A number of API 2.0 bugs (besides the database bugs noted above were fixed):

  • TextArea.SelectionAlignment now accepts enum values.
  • String.IndexOf now properly matches its signature when you leave off the startPosition but include ComparisonOptions or Locale.
  • If an empty name is used in the TimeZone constructor it will create an instance for the current timezone.
  • String.LastField now works
  • SerialConnection.Connect no longer raises an Error event.  It now throws an exception as expected.
  • DateTime no longer reports a Nil TimeZone

In Windows, having multiple HTMLViewers on a window (or multiple windows) no longer continuously switches focus.

In MacOS setting FolderItem.Visible no longer inverts the visibility.

The Plugin SDK now lets you access the new API 2.0 string extension methods.

The burning question that everyone wants to know:  Do I think that Release 3.1 is safe to use?  The answer is a definite maybe.  Let me explain.

I’m still not sold on API 2.0 being completely stable.  A few additional bug reports were filed after R3.1 was released including a GenerateJSON bug with Variant arrays (Feedback 58940), and a DatabaseColumn.Value bug where value always returns a String value (Feedback 58934) where it should be bringing back the correct data type.  Both of these bugs are marked as fixed and ready for 2020 R1.  Unfortunately we don’t know when R1 will drop but if I was a betting person I’d guess sometime in March either the week of Xojo.Connect or maybe even later.

If you’re using Classic API then I believe R3.1 is safe(ish).  I’ve experienced some oddities in the Constants Editor but I can’t replicate an issue where it reverts the value with no intervention on my part.  The new ColorGroup Editor for iOS projects just seems sluggish but that may just be the result of the new ColorPicker.  If you’re doing iOS projects you pretty much have to use R3.1 to stay up to date.

I have migrated a few projects to R3.1.  A few that I’ve attempted have had compilation issues and I haven’t gone back to determine if they were plugin or code issues and frankly I’m not that big of a hurry to upgrade.  R1.1 is still working fine for me and I don’t need the hassles involved with major Xojo upgrades.

So my advice is to test the heck out of your projects if you upgrade to R3.1.  I say this every release (because its true) but if you’re using API 2.0 then massive testing is a necessity. I put it this way: do you want to bet your company and/or product on trusting a new API?

What is your experience with 2019 R3.1?  Is it worthy?  Are you holding back and, if so, why?

Why Do People Leave Xojo?

I’ve been a member of the Xojo community for nearly twenty years.  In that time I’ve seen a lot of people join the community, become fantastic contributors, and then suddenly leave the community.  There are a lot of reasons developers would leave the community but I thought I’d capture some of them.

Xojo scratches an itch and if the developer no longer has the need to scratch that itch they use a tool that scratches their next itch.  Xojo is great for cross-platform applications but certainly less so if you need only a Mac or only a Windows application.  Xojo’s strength is cross-platform which means compromises in abilities and controls so I can understand people wanting a pure Windows or MacOS application.  Apple and Microsoft have large developer communities that are attractive.

The Rapid Release Program held much promise when it was introduced many years ago.  Xojo went from two big monolithic releases a year to three, four or more releases per year.  Sure, Xojo fixes a ton of stuff in each release but they also seem to break stuff in each release.  I know we have a list of verboten releases for various platforms and it gives the impression of a perpetual beta status for Xojo.  I have been a big fan of releases that are almost all bug fixes with no new features but those are pretty rare.

Xojo is a modern object oriented language and is quite powerful but it’s not a popular language.  Many developers have never heard of Xojo.  There is no standards committee that adds features to the language and the language itself is closed source.  If there was a standards committee I suspect there would be some serious language additions done sooner rather than later.  It certainly would have given much more forethought into API 2.0 and how it would affect the existing user base and the documentation done long before any coding started.

Xojo isn’t like any other development tool I’ve ever used.  It’s great that it doesn’t allow a developer to make a stupid mistake when declaring a method.  It forces you to use the Xojo IDE user interface to do everything from creating methods, declaring properties, constants, enums, etc.  I’ve never used another developer tool that does this.  Xojo pretty much forces you to use it the way they want you to rather than what most other languages do with a text editor.  This makes it easier for beginners but if I’m being honest it’s a drag for someone like me that (usually) knows what they are doing.  Forcing developers into the Xojo-way of doing things makes the IDE seem like a toy at times.  It’s certainly slower.

Change does not happen quickly with Xojo.  It has a small development staff and I’m always amazed at how much they get done.  But it means that it can take an incredibly long time for things to change and become stable.  The transition to 64-bit was a huge multi-year project.  iOS was a huge multi-year project.  Web 2.0 and Android have become huge multi-year projects (with still no idea on when we’ll see them).  The new targets might be good eventually but history shows it will take a few releases before they’re really stable.  Meanwhile older targets seem to get significantly less attention.

Xojo isn’t really a business development tool.  When I say business I mean databases and reports because that’s practically every application we’ve done for the past twenty years.  Doing database development in Xojo is NOT Rapid Application Development (RAD) because you have to deal with everything database related yourself and the IDE and compiler give you zero help.  Reports are simplistic and aren’t exceptionally powerful and there’s no way for an end user to create or edit reports.  There’s a reason why BKeeney Software has its own database Object Relation Model (ORM) classes and reporting tools and classes because we have to use them in nearly every project we do for clients.

In addition to all that it’s really missing some things that business users need.  The TextArea control has pitiful RTF support, there is no built-in calendar, date, or time controls.  The built-in grid (Listbox) is more powerful than many people give it credit for but cannot hold native controls and can be very slow with large data sets.  There is no PDF read or write support either.  There are 3rd party options for all of these things but something lightweight would go a long way to supporting new business users.

These are a few of my thoughts.  What am I missing about developers that leave Xojo?  And is there a way to stop them from moving away from Xojo?  What are they doing to?