Xojo Can’t Math

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

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

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

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

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

Anyway, happy coding everyone!

Wanted: Xojo ‘Snow Leopard’ Release

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

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

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

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

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

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

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

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

Is that too much to ask?

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.

Xojo 2020 Release 1

Xojo 2020 R1 was released today.  The last major release of Xojo came nearly 9 months ago.  This much anticipated release has a completely rewritten from the ground up Web API that takes Xojo web applications to a whole new level in terms of look and feel with themes, new controls, and new functionality.  This release also brings a ton of new and improved functionality to desktop applications too.  Let’s dive into it!

Web 2.0

The elephant in the room in this release is Web 2.0.  Web 2.0 is a complete reimagining of what Xojo web applications look like.  

Controls galore.  Web 2.0 comes with all of the web 1.0 control (see exception below) and a host of new controls that look and feel really nice.  Among the new controls:  Audio Player, Breadcrumb, Chart, Date Picker, Pagination, Search Field, and a host of specific TextField types like email, number, password, and telephone.

Every standard control (buttons, text fields, etc) have a wide variety of new options that I think will make developers happy.  The new WebListbox has monster changes and I really can’t do it justice in this review.  Among some of the big additions is the ability to load data dynamically using the WebDataSource.  If you’ve used iOS in Xojo it acts pretty much the same way and allows you to have practically unlimited numbers of rows of data and it will load the data as the user scrolls.  This means you don’t have to page your data (though you can if you want by loading the data manually in combination with the new Pagination control).

Even more interesting are the new WebListbox Cell Renderer classes.  In this release there are four built-in with DateTimeRenderer, ImageRenderer, StyleRenderer, and TextRenderer (the default renderer that doesn’t need any special action on your part).  The DateTimeRenderer lets you specify the Date and Time format styles but also a Relative Style (like “Today” and “Yesterday” values with time) and it also localizes the data to the users locale.  The ImageRenderer is pretty straightforward to view images, the Style lets you set the style of an individual listbox cell and, of course, the TextRenderer is the default.  The WebSDK example comes with a Button Cell and Color Cell renderer too so it should be exciting to see what developers do with for this.

While Web 1.0 had WebStyles they really were hard to use. Web 2.0 uses Bootstrap and that gives you an incredible amount of variety available in your Xojo web applications.  While there’s a default bootstrap theme there is no theme editor in this initial release but it’s not so hard to change the theme on your own.  One way to change the theme is to go to https://pikock.github.io/bootstrap-magic/, save the css file to your computer, rename the file to boostrap.min.css and add to your project.  Users can download pre-made bootstrap 4 themes from bootswatch.com.  Unfortunately the IDE doesn’t render these themes very well but it works at runtime.

Web 2.0 projects compile only to standalone now so you no longer have the option of using a cgi version.  Xojo Cloud users automatically get load balancers for your applications and you get the same number of application instances as you number of cores on your server plan.

While most of Web 2.0 is very exciting and enticing those that have an existing Web 1.0 project will most likely not be very happy.  The conversion process is a one way process and not everything converts.  WebAnimator does not have a Web 2 counterpart and WebStyles are completely reimagined so while the compiler won’t complain if your code uses an old WebStyle it’s pretty much ignored.  I would even say that the conversion to Web 2 is broken to the point where it would be easier to rewrite your project into Web 2 than it is to try and convert it.  Default control heights in Web 2.0 (38 pixels tall but depends on the theme) are considerably bigger than Web 1 (22 pixels) so I find it hard to imagine that most layouts wouldn’t need considerable work to get correct for Web 2.0.  It sucks, but that’s the reality of it.

There are some missing parts in the IDE that are disappointing as well.  The WebToolbar and WebStyle editors are missing in Web 2.0 but the good thing is that both can be created in code.  Web 2.0 does not have control sets implemented at this point.

It’s also disappointing that not all of the Web 2.0 examples are working properly or are so simple as to be useless in learning how to use Web 2.0 (I’m looking at the WebListBox examples).  The documentation for Web 2.0 isn’t as clear cut as I’d like too and I disagree with some of the property groupings for the Inspector.  For example in a WebLabel and WebLink there are Font properties to set the font properties but a WebTextArea does not have this and you have to manually set them via the Style property.  Why does one control have it exposed and another one does not?  Xojo has one shot to impress developers with this release and inconsistency is a bad look in my opinion.

Everything Non-Web 2.0

While Web 2.0 is by far the biggest part of 2020 Release 1 but it is not the only important change.  Here are some of the highlights.

Desktop Changes

Listbox Header drawing events.  New in R1 is ListBox.HeaderBackgroundPaint and HeaderContentPaint.  This allows the developer to have total control over the drawing of the headers.  Want to draw an image, or change the background color, or even change the sort indicators?  No problem now with these two events.

TextArea now has a UnicodeMode that allows you to change the way the control treats characters.  The default is Native and that doesn’t change anything.  The Characters setting counts by the single character regardless of the byes used and the Codepoints setting counts by number of Unicode Codepoints (bytes) it requires.  The Codepoints way is what you’d have to use for an emoji.  This is a nice addition from the the old Xojo Framework.  They also now have a String.Characters iterator.

For years Xojo developers have had to rely on third party plugins to create PDF documents in Xojo applications.  New in 2020 R1 is the PDFDocument class that allows you to create a PDF document fairly easily using simple graphics object commands.  PDFDocument does not support transparency so you’ll have to consider the order that you’re drawing items and you might find it hard to create some forms of documents.  All in all this is a great addition to the product that many people will like.  PDFDocument is available in all targets excepts iOS. It’s not perfect but for many users it will be good enough and hopefully they’ll add some features to it in future releases.

Linux applications now have a Normalize Control Sizes build option.  It normalizes the controls widths/heights, removing theme specific padding and adjustments to make controls on any Linux distribution look similar.

XojoScript’s can now be saved in their compiled form into a MemoryBlock and that means you can read and write them to a file.  This should allow XojoScripts to be considerably faster since they may not have to be recompiled every time they’re used.  If you use XojoScript I think you will really like this feature.

HTMLViewer has a new event called JavaScript request that gets raised when using the ExecuteJavaScript and ExecuteJavaScriptSync methods.  This should eliminate the need to use third-party code to do the same thing.

Project loading and compiling of desktop applications is considerably improved.  In my testing it’s about the same speed as Xojo 2019 R1.1. Gone is the slow down users experienced after they did a check project.

There are dozens of other bug fixes and changes that I could tell you about but I’ll leave the joy of reading the release notes to you.  Why should I have all that fun?

Overall Impression

Xojo 2020 R1 is a huge release that’s been in the making for long time (if we’re being honest the wait was too long).  Web 2.0 has a lot of exciting new features, controls, theming options that should excite developers.  Converting projects is very hard and I think learning the new controls is harder than it needs to be with incomplete documentation and examples that are either not working or weak.  I really don’t have a real good feel for how stable Web 2 is simply because I’m not working on any web projects currently.  I suspect that there are bugs to be found as more people start stress testing it.  But it’s a good start and I look forward to the missing pieces being filled in as time goes on.

Obviously Web 2.0 is the big star of this release but the PDFDocument class is a great addition that users have been asking for years.  The other bug fixes and changes are also big and even if you aren’t a Xojo web developer this is a big and important release. I’ve been using R1 for desktop apps (Mac and Windows only) and I’ve found it to be stable and I have no complaints (other than no being able to turn off API 2 items).

What say you Xojo developers?  Is Web 2.0 worth the wait?  Is is stable?  What do you think it’s lacking?  What do you think about the desktop changes?

A New Version of ARGen

Tim Parnell of Strawberry Software has released a new version of ARGen with some exciting changes. New to the ActiveRecord utility is a Microsoft SQL Server database adapter class utilizing the SQLDatabaseMBS plugin (you’ll need an MBS license for this). Now your Xojo Mac application can use a SQL Server database.

ARGen is a great utility that generates Xojo code, classes, and user interface elements (think basic list and add/edit windows) that ties interfaces to your database. ARGen can save you many hours of tedious coding by abstracting the database code to read, write, and interface with controls.

Another new feature is called Quick Resolve that will automatically deselect incompatible tables. ARGen will show you an error view if you have tables that do not have primary keys (ActiveRecord requires tables with a primary key), or other errors, and allows you to remove them from the list. This should be a big time saver for some Xojo developers.

Postgres database server users can now use SSL connections.

The namespace template has been updated to provide thread connection pooling for Desktop targets.

For large databases ARGen is now faster in the project generation with improvements to the internal XML creation.

Many more improvements, tweaks, and bug fixes are in this release.

The 2020.02 release is free for existing 2020 users and is highly recommended for all users. Be sure to check out the product page as there have been a number of changes since I last posted about ARGen.

For more information and to download please visit https://strawberrysw.com/argen.

The newest version of ARGen

ARGen is no longer a BKS product but I’m still a user and I’m very excited about the things that Tim from Strawberry Software has done with it in the new release. Besides an obvious facelift there are some very nice features that have been added.

API 2.0 is now supported along with classic API. This should come as no surprise since Xojo moved to API 2 that ARGen would eventually support it and was a highly requested feature. If you select API 2 all code will switch over to the appropriate syntax for you including all of the hidden Xojo database classes that ActiveRecord uses. If the project type doesn’t support API 2 (like Web and iOS projects) it’s not an option.

Multiple database connections/classes supported in one project. Way back when we originally created ARGen and ActiveRecord we never envisioned that we’d ever want more than one database in a project. Thinking back that was a silly assumption but in ARGen 4 you can now have multiple databases, or namespaces, and each one does its own ActiveRecord thing.

Console project type added. Again this is a silly oversight on our part long ago but since since we didn’t do many console projects it makes sense that we didn’t have it. This should make adding helper apps much easier.

A new Verify class function detects deleted fields. ActiveRecord has always been able to detect newly added fields when running in the debugger that warned the developer if the Xojo class was missing a property for a database column. The new Verify class does the opposite: does your class contain a property that at one point we thought was a database column but no longer exists in that table? Before this version that was a silent failure as it didn’t detect it so at least now you can take care of it right away. When working on a big project with multiple developers touching the database this will be a huge help.

Foreign keys that are nil are inserted as NULL values. This was always a huge user request that ARGen handles gracefully. Whereas before it inserted zero’s or blanks (depending on primary key field type) it will now put NULL’s where appropriate. This allows better relational integrity and plays better with relational databases.

The User Interface generation has been cleaned up. No longer do you have the choice of a regular window and/or container for lists and add/edit UI – everything is a container control and this simplifies some choices that I think most users will really like.

Remember that ARGen is all about getting your Xojo database project going as quickly as possible that the tedious coding part is done for you. This version of ARGen takes that to the next level with many of these features. Obviously Tim will tackle Web 2.0, iOS API 2 and Android whenever Xojo releases them to the public. The future of ARGen is bright!

There are little changes throughout the product and the resulting project that I think you’ll be happy to see. A new ARGen license costs $99. Existing ARGen (from BKS) users receive a 20% discount when upgrading. All existing users should have received an email but in case you haven’t please send an email to workshop@timi.me.

For more information on ARGen 4 please visit https://strawberrysw.com/argen/.

Whither Xojo 2020 Release 1

The Xojo drought we’re experiencing in 2020 is starting to become ridiculous.  The last release, Xojo 2019 R 3.1, was released January 23rd, 2020.  As of today we’re at 152 days.  

The longest previous delay between releases was 143 days between Xojo 2012 R2.1 (January 12, 2013) and 2013 R1 (June 4, 2013).  If I recall correctly this was the transition from Real Studio to Xojo and was when the IDE went through a massive redesign (and ironically I was accused of causing a 6 month delay due to a blog post).

Come on Xojo.  There are plenty of bugs and enhancements that should be shipped NOW.  Is the Rapid Release Model being replaced with once a year monolithic releases?

Write Code That Your Future Self (and Others) Won’t Hate

One goal we should all strive for is to write code that is clean and simple enough that when we look at it six months or six years from now there’s no issue figuring out what it does. Or, as I like to put it, write your code so that your future self doesn’t invent a time machine to keep you from doing something stupid.

This week Javier from Xojo wrote a blog post at https://blog.xojo.com/2020/06/03/using-class-extensions-to-validate-email-and-url-data/ that shows the simple string extensions IsEmail and IsURL. On their face these are nice examples of using Extension to do something useful in Xojo.

Everything is fine until he says this:

“With using the “ByRef” keyword we are instructing Xojo to give us access to the original data; and in that case we will be able to modify the received data through the given variable name in the Parameters field.”

Again, on its face it’s no big deal but this is exactly what my future self would have a conniption fit about. Why? Because when I see IsEmail and I get a boolean back I will assume (as would most developers) that it’s a simple check to see to see if the string is a valid (or valid enough) email. What I absolutely would not expect is for my source string to get modified.

You see, “IsSomething” means true or false in my book. Not, I’m going to mess with your original data. So when your future self sees that there’s an IsEMail method are you going to go look to see the implementation details? Of course not because IsWhatever that returns a boolean seems pretty straightforward and your boss needed the code yesterday.

If you’re going to create a method that massages the data I wouldn’t use an “Is” prefix. Perhaps an extension method that does this should be named “TestAndReturnEMail” because then you’ll at least look at it and go what the hell was I thinking. But then again, using Extends is probably not idea for testing and modifying a string you think is an email. There’s probably a half dozen ways of doing this better.

My general rule of thumb: if you have to look at the guts of a method to determine what it does you’ve already lost. You really think you’re going to remember that IsEmail six years from now mucks about with your original string? I know I won’t.

In my opinion this is the exact wrong place to use ByRef. Feel free to disagree but if I had one of my developers do this I’d be very disappointed.

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!