twinBASIC Update: September 5, 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

IntelliSense in the Debug Console

Thanks, Wayne!

Wayne had to work around some technical limitations of VS Code, so don't expect this to be a perfect replacement for the VBA Immediate Window.  I'm just glad he got it working at all.

It was a bit tricky to implement, as the DAP only allows for intellisense and not signature-help, plus the DAP CompletionItem is much less flexible than the LSP equivalent.

Anyhow, we've included both normal intellisense results AND signature help (when appropriate).  The intellisense is context aware of the code being debugged, prioritizing local scoped results (e.g. local variables) then component-scoped results (e.g. global variables / class fields), and then everything else.

Whilst this is not a perfect solution, it is greatly superior to what we had before... and I feel this satisfies this request, and is the best implementation we can do given the current (limited) DAP support for this feature.

Unit Testing Improvements

  • AreSame and AreNotSame implemented in v0.10.5276
  • IntelliSense/Signature help added for Assert members

Unit Testing Now a Standalone Library

From Wayne Phillips:

As of v0.10.5165, the Assert modules are now only available if explicitly referenced in the project Settings:
This library does not add any dependencies to the compiled project, as assertions are only evaluated whilst debugging.

#Error and #Warning Directives Added

You can now raise custom errors or warnings during compilation based on conditional compilation logic:

The #Error directive will always block compilation if encountered.

The #Warning directive will emit a compiler warning by default, but that behavior can be adjusted via Compiler Warning TB005:

Around the Web

Non-commercial / hobbyist License Update

The discussion continues on the possibility of a non-commercial/hobbyist license and what such a thing might look like.  My favorite suggestion in the thread–assuming its technically feasible–comes from FullValueRider:

Once such method could be a constraint that without a paid for license, twinBasic output would be restricted to run only on the combination of internal compiler Id/computer/office installation that generated the code.

Be sure to join the discussion if you want to influence the future of a hobbyist license.

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.10.5452, 5th September 2021]

[v0.10.5451, 5th September 2021]

[v0.10.5450, 5th September 2021]

[v0.10.5422, 4th September 2021]

[v0.10.5278, 2nd September 2021]

  • fixed: debug & run window getting focused automatically when opening a project in VS Code 1.60 due to change of handling in VS Code

[v0.10.5277, 2nd September 2021]

  • fixed: breakpoint compatibility with VS Code 1.60, due to change of noDebug flag handling in VS Code

[v0.10.5276, 31st August 2021]

[v0.10.5220, 30th August 2021]

[v0.10.5165, 30th August 2021]