twinBASIC Update: November 21, 2021

Mike Wolfe -

On April 23, 2021, I helped Wayne Phillips introduce the world to twinBASIC at the Access DevCon Vienna conference.  I boldly predicted that twinBASIC (along with the Monaco editor) would replace VBA and its outdated development environment by 2025.  With that goal in mind, this weekly update is my attempt to keep the project fresh in the minds of the VBA development community.

Every Sunday, I will be providing updates on the status of the project, linking to new articles discussing twinBASIC, and generally trying to increase engagement with the project.  If you come across items that should be included here, tweet me @NoLongerSet or email me at mike at nolongerset dot com.

Highlights

64-Bit Compilation is Here!

The big news this week is that twinBASIC now supports 64-bit compilation.

Wayne is referring to this as a MILESTONE RELEASE.  Here are the release notes:

To get started, first you need to create a win64 build configuration in your projects.  To help you, when you first open your projects in v0.13.1, the IDE will prompt you to create one:
You should now see the build configuration appear in the explorer:
Now you should be able to activate the win64 build configuration:
After selecting win64, you'll be prompted to restart the compiler. After doing so, you'll be debugging and compiling in full glorious 64-bit.  Have a nice weekend folks!

Around the Web

64-Bit Compilation Available for All

There's been a lot of discussion around how best to set up licensing for twinBASIC.  The early plan was to make 64-bit compilation a feature that required the purchase of a license.  

For the time being at least, 64-bit compilation will be available to those without a license.  There will be a five-second splash screen that will be shown if you do not have a commercial license.  This seems like a good compromise to allow hobbyists to adopt twinBASIC and help grow the overall community.

Plans for Handling References & Versions?

Ben Clothier started a discussion about how best to handle external references:

With VBx projects, external references can be a huge PITA:

  • A reference gets compiled with the full absolute path which may not exist on the target machine.
  • A reference may be compiled using a higher version than the one that exists on the target machine, even though the code is otherwise compatible for lower version. This forces the developer to build the project using the lowest version available which generally works on computer with higher versions.


Typically, one can avoid all those ugliness by using late-binding but that is not always desirable. One particular pain point is when one wants to use events.


Will twinBasic have plans for making this a better experience? Can it be made better? Can we control how to resolve the missing reference at runtime?

In one of Wayne's responses, it sounds like twinBASIC will be able to deal with missing references on an end user computer much more gracefully than VBx.  In VBx, if you use early binding and the reference is not available on the end user computer, then the application exits at startup without giving you as a developer the opportunity to even catch and handle the error.

This ability to catch missing reference errors at first use is one of the biggest advantages of late binding.

With twinBASIC, it sounds like that ability may be available with early binding, too.  Here's Wayne:

Unlike VBA, at runtime, tB doesn't really resolve references as such; that part happens at compile time.   So at runtime you've got two main types of dependencies for each class that is referenced:  the CLSID of classes that get instantiated, and the IIDs of the interfaces that we expect each class to support.

If this is the case, it is a HUGE improvement over VBx behavior.  It would make early binding a better option than late binding in twinBASIC in many situations where the opposite is true in VBx.

Change in twinBASIC versioning

Careful observers may notice that beginning with v0.13.1, the twinBASIC version numbers no longer include build numbers.  According to Wayne, that's because there are separate builds for the 32-bit and 64-bit flavors of the twinBASIC compiler.  Thus, each new tB version would generate two different build numbers.

Also, the version number is now shown on the twinBASIC panel as shown in the screenshot below.

The version number is also visible in the call stack window and VS Code twinBASIC extension page.

Changelog

Here are the updates from the past week.  You can also find this information by installing the twinBASIC VS Code extension and clicking on the Changelog tab of the extension page:

[v0.13.4, 21st November 2021]

[v0.13.3, 20th November 2021]

  • improved: sample projects now updated to include RegisterAddin64 / UnRegisterAddin64 registry files where appropriate

[v0.13.2, 20th November 2021]

[v0.13.1, 19th November 2021]

  • milestone release: PREVIEW 2
  • added: full 64-bit compilation support, including EXE/DLL builds, integrated debugger, integrated linker, etc
  • fixed: linker error causing DLL projects that use CustomControls to crash