Xojo 2020 Release 2

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

BKeeney Shorts Has a New Home at Varcess

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

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

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

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

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

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

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

Xojo Can’t Math

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

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

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

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

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

Anyway, happy coding everyone!

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.

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!