twinBASIC Update: June 13, 2021

Highlights include Like statement support and a new VS Code command to create new project files (no more downloading .zip files from!).

twinBASIC Update: June 13, 2021

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.


There were some big milestones this week in twinBASIC's development.

Create new project command

Prior to v0.10.1386, the only way to get started with a new twinBASIC project was to grab one of the sample files from the twinBASIC preview page.  You can now create new projects without ever having to leave VS Code.

  1. Open VS Code (ensure you have the twinBASIC extension v0.10.1386 or later)
  2. Press [F1] on the keyboard
  3. Begin typing: twinBASIC: Create new project
  4. When twinBASIC: Create new project is highlighted in the dropdown, press [Enter]
  5. Use the up and down arrow keys to choose your preferred project type

Project Types

You can choose from one of 7 different options.  Sample 4 lets you create an add-in for the VBA development environment, which can be useful to you while developing applications and writing code.  Sample 5 lets you create an add-in for the host application–such as Access or Excel–that you could use to expose functionality to your end users.

Screenshot: choose the type of project to create: pick from 2 standard project types and 5 sample templates
There are two standard project types and 5 sample templates (so far).
  1. ActiveX DLL: choose this option if you want to create a code library that you can call from VBA
  2. Standard EXE: choose this option to create a standalone program that you can run from the command line
  3. Sample 1. HelloWorld: produces a standard EXE that shows a MsgBox with the text "Hello, world."
  4. Sample 2. GetIPAddresses: demonstrates how to make Windows API calls in twinBASIC
  5. Sample 3. MyCodeLibrary: demonstrates how to create an ActiveX DLL and call it from within VBA
  6. Sample 4. MyVBEAddin: demonstrates how to handle the VBE events provided by the IDTExtensibility2 interface (be sure to read the additional instructions to implement this sample); this is used to create an add-in within the VBA development environment
  7. Sample 5. MyCOMAddin: demonstrates how to create a COM add-in that also provides access to the host application's ribbon; this is used to create an add-in within the main host application (e.g., Excel or Access)

Support for the Like operator

This is another big hurdle cleared for those who want to be able to copy code from VBA/VB6 and paste it into twinBASIC.  The lack of support for the Like operator made this a major challenge.

In fact, when I presented twinBASIC at Access DevCon Vienna, I listed this as one of the five biggest limitations of the twinBASIC preview:

The Like operator is now available in twinBASIC.

Big shoutout to Cristian Buse who created an automated test suite of over 20,000 test cases to help identify the quirks of the Like statement.  Along the way, several improperly handled edge cases were discovered in the original VBA/VB6 implementation.  

It remains to be seen how Wayne will handle bugs discovered in the original VBA/VB6 implementation.  As I mentioned in my twinBASIC presentation, the ultimate example of preserving legacy quirks comes from the original Windows development team.  Here's the story as retold by Joel Spolsky:

"SimCity...happened to work OK on DOS but would not work under Windows...[T]he Windows developers...disassembled SimCity, stepped through it in a debugger, found the bug, and added special code that checked if SimCity was running, and if it did, ran the memory allocator in a special mode in which you could still use memory after freeing it."

Around the Web

If you–like me–are curious about the inner workings of VBA and VB6, then I highly recommend you subscribe to receive notifications from the twinBASIC GitHub project.  Even if you have no interest in ever using twinBASIC, much of the discussion revolves around the existing low-level implementation details of VBA and VB6.  

Go to then click on Notifications in the top-right corner of the page and choose "All Activity."  You will need a GitHub account if you don't already have one.

I'll post a few excerpts from discussions that I found particularly interesting this week in the space below.

Improved handling of locales & invariant

Ben Clothier started a discussion about how best to handle string comparisons in twinBASIC.  As my international readers will attest, this is an area where VBA/VB6 is particularly deficient.  The Unicode support in VBA is lacking, to say the least.

Describe the solution you'd like
We should be able to specify at the module level whether we want to use a specific locale or more broadly control those elements:

  • Lettercase sensitivity (we already have that with the Option Compare [Text | Binary])
  • Accent sensitivity
  • Kana sensitivity (applies to Japan locales)
  • Width sensitivity (applies to East Asia locales for non-Unicode code pages, I think)

As a possible example we could allow the syntax:

Option Compare Text Case Sensitive, Accent Insensitive

(only allowed on Text, not on Binary)

For a good example of different collations, this SQL Server article on the collation is a good start.

Super Performance on Class Freeing

GitHub user Kr00l started a discussion with the results of some twinBASIC performance testing he had done.  Apparently, freeing large numbers of objects in VB6/VBA is a drag on performance.   This is not something I was aware of, though I should add I've never had a situation where I had to free thousands of objects from memory at one time.

In any case, Kr00l's tests show that twinBASIC does not suffer from this performance impact the way that VBA/VB6 do.  Here's an excerpt from his post:

In VB6 it is quite known that Instantiation a bulk of class instances goes quite fast.
However, the class freeing begings to slow down progressively! So fast at the beginning but slows down dramatically..

Giving the below code as an example, the VB6 freeing times are as following:
100k = 0.3902
200k = 2.2432
300k = 6.2895
and so on..

tB is currently super duper fast on this, which is exciting.
VB6 is so slow on this due to the IConnectionPoint-Containers and it's COM-Eventmechanism.

tB does here a direct callback to Class_Initialize and Class_Terminate ?

This is not a feature request or bug report. I just wanted to point this out as this is actually a good benefit !


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.10.1455, 13th June 2021]

[v0.10.1444, 11th June 2021]

[v0.10.1389, 9th June 2021]

[v0.10.1386, 9th June 2021]

[v0.10.1315, 9th June 2021]

[v0.10.1204, 8th June 2021]

[v0.10.1199, 8th June 2021]

[v0.10.1168, 7th June 2021]

[v0.10.1164, 7th June 2021]

[v0.10.1154, 7th June 2021]

[v0.10.1111, 7th June 2021]