twinBASIC Update: June 20, 2021

Highlights include custom events in twinBASIC classes, full Debug.Print syntax support, and an experimental code prettifier.

twinBASIC Update: June 20, 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.


I continue to be amazed at the pace at which Wayne is able to release new features of the twinBASIC language.  This week was no exception.  There were 11 public version releases and (by my count) three major features.

Custom Events

twinBASIC classes can now define custom events and class members can raise those events.  

For a quick primer on raising custom events, see my article: Raising Custom Events in VBA.  I copied and pasted the Funnel Ball classes from that article into a new twinBASIC Standard EXE project and everything worked like a charm:

Full support for Debug.Print syntax

When I gave my twinBASIC presentation at Access DevCon Vienna, I listed 5 noteworthy limitations of the twinBASIC preview release.  These were the types of limitations that could lead to compile errors when converting existing VBA code.

  1. Generic Error Descriptions
  2. No Like operator
  3. No Global/Module-level variables
  4. Debug.Print syntax not supported
  5. No built-in file operations

With the release of twinBASIC v0.10.1604, we can cross another limitation off the list.  twinBASIC now fully supports the special Debug.Print syntax, where semicolons are used to concatenate arguments and commas are replaced with tabs.

Code prettifier (EXPERIMENTAL)

The VBIDE does some automatic code formatting to standardize the way VBA/VB6 code looks across projects.  For example, it enforces a single space between keywords; no spaces between parens and neighboring characters; a single space between identifiers and mathematical operators; etc.

It also enforces standard letter casing, but it does it in the most horrific way possible: by changing the casing of every identifier in the entire project, regardless of scope.

twinBASIC takes the much more sensible approach of treating the initial declaration of a variable (or class name or function name, etc.) as the authoritative version.  Any other instances of that identifier will have their case auto-corrected to match the initial declaration.  The feature respects scoping, so you won't accidentally clobber the letter casing of code in unrelated parts of your program.  This is a huge win for version control compatibility.

Maybe this is silly, but this is one of the features of twinBASIC about which I am most excited:

Around the Web


With the recent announcement of an upcoming Windows 11 operating system, Andrew Mansell raises the possibility of Microsoft dropping support for VB6 in the new OS:

Microsoft has previously committed to supporting the VB6 runtime for the lifetime of Windows 10. As Win10 was supposed to be the "last version of Windows", this implied support in perpetuity.

However, it seems this has changed. Windows 11 is rumored to be on its way, and Microsoft seem set to retire Windows 10 in 2025 . I would be amazed if the VB6 runtime is supported in Win11.

So, twinBasic appears to offer (a? the only?) lifeline for VB6 projects. No pressure @WaynePhillipsEA!

Respectfully, I have to strongly disagree with Andrew on this one.  I for one would be shocked if Microsoft dropped support for VB6 in Windows 11.  

As far as I'm aware, the cost for continuing to provide VB6 support in Windows 11 would be minimal.  Thus, the only compelling reason to remove it would be if Microsoft wanted to force all the legacy VB6 applications to migrate to a different language.  

That's the sort of bet you make early on when you are trying to build critical mass in a brand new programming language.  In other words, the situation 15 years ago when Microsoft was trying to get all the VB6 developers to switch to VB.NET.  

At this point in the game, forcing such a switch would generate bad PR with very little upside for Microsoft.  I just don't see it happening.

Workspace Trust in Visual Studio Code

The May 2021 release of Visual Studio Code introduced Workspace Trust.  This new feature is meant to provide extra security against code execution when browsing unfamiliar source code.

Along with many other VS Code extensions, twinBASIC appears in the list of Disabled extensions when VS Code is running in Restricted Mode.

What this means in practice for twinBASIC is that you will need to add your workspace files to "Trusted Folders" to continue editing them (or simply disable the Workspace Trust feature altogether, though Microsoft does not recommend this).


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.2235, 20th June 2021]

[v0.10.2166, 19th June 2021]

[v0.10.2122, 18th June 2021]

[v0.10.1923, 17th June 2021]

[v0.10.1844, 16th June 2021]

  • fixed: memory allocation error in the debug console handler, causing the debug console to be fragile

[v0.10.1841, 16th June 2021]

[v0.10.1628, 15th June 2021]

  • fixed: Spc/Tab in Debug.Print statements had no semantic highlighting
  • fixed: intellisense could crash-restart the compiler when hovering over calls that were ambiguous or unmatched

[v0.10.1619, 14th June 2021]

[v0.10.1616, 14th June 2021]

[v0.10.1615, 14th June 2021]

[v0.10.1604, 14th June 2021]

All original code samples by Mike Wolfe are licensed under CC BY 4.0