twinBASIC

Preview Limitations in twinBASIC

CAUTION! twinBASIC is a work-in-progress. To avoid frustration, learn what's not working *before* you start playing with it.

Mike Wolfe

Apr 17, 2021 • 5 min read

To learn more about twinBASIC, join me at this year's virtual Access DevCon where I will be presenting this exciting new project from vbWatchdog creator, Wayne Phillips.

A work in progress

As I wrote yesterday, twinBASIC's goal is to achieve 100% backwards compatibility with VB6/VBA. As the project is a work-in-progress, there are several items that are not currently working.

If you're trying out a new language, you can save yourself a lot of frustration by knowing its limitations ahead of time. This list is intended to provide you with the current state of the project's limitations. More importantly, the links at the bottom of the post will help you stay current with realtime updates on the project's progress.

Those links will be your best source for up-to-date information about the twinBASIC project in the weeks and months ahead. I've posted lots of articles on twinBASIC leading up to my DevCon talk this week, but I plan to return to my "regularly scheduled programming" following the conference. I will continue to post about the project, but on an occasional–rather than daily–schedule.

The Highlights

In this first section, I want to highlight the things that I think are most likely to trip you up at this early stage of the project's development:

Generic Error Descriptions

You might not think this is a big deal at first, but it's bitten me a few times. On more than one occasion, I've assumed one of my own silly mistakes was actually a bug in twinBASIC. For example, consider this code snippet in twinBASIC:

Unspecified error. Whatever could that be?

If I run the same code in VBA, my carelessness becomes obvious:

I make this mistake more than I care to admit.

The Like Operator

I use the Like operator regularly in my code. If I tried to convert almost any of my standard code library modules, this would almost certainly trip me up:

If "Test Case" Like "Test*" Then Debug.Print "True"

This valid VBA code won't compile in the current preview release of twinBASIC.

Global/module-level variables not supported

Here's another limitation that will be a major stumbling block when trying to convert existing code to twinBASIC. Note in the screenshot below that even private variables declared at the module level are not yet supported.

Debug.Print syntax

In VBA, you can separate strings in the Debug.Print statement using semicolons and commas. That syntax is not yet supported in twinBASIC:

Use this instead: `Debug.Print "Bitness: " & 32 & vbTab & "Year: " & 2021`

Built-in file operations

The file operations built in to VBA itself are not yet supported. This includes File Statements and the FileSystem namespace of the standard library.

The File Statements are Open, Close, Reset, Seek, Lock, Unlock, Line Input, Width, Print, Write, Input, Put, and Get.

The FileSystem functions are CurDir, Dir, EOF, FileAttr, FileDateTime, FileLen, FreeFile, Loc, LOF, and Seek.

The FileSystem subroutines are ChDir, ChDrive, FileCopy, Kill, MkDir, RmDir, and SetAttr.

The FileSystemObject should be able to provide much of the above functionality until twinBASIC fully implements it.

The Official List

I've paraphrased the official list of limitations from the twinBASIC Preview page:

32-bit only
Error numbers/descriptions don't match VB
Global/module-level variables not supported
Classes can't expose events
Late-bound calls to twinBASIC classes not supported

Car must currently be declared `As oVehicle` to reference its properties and methods.

Multi-threading only supported in debug console
vbWatchdog support disabled
Webserver extension library disabled
VBA.Interaction.* and VBA.Strings.* have limited test coverage
With blocks not working with user defined types

RegSvr32.exe can't be used to register DLLs on other computers
VS Code sometimes needs to be closed and reopened
Only one .twinproj (source code) file allowed
VS Code uses excessive memory due to known leak

Pending syntax support

The following syntax is not yet supported:

File statements: Open, Write, etc.
VBA.FileSystem.* namespace

The FileSystem namespace is not yet supported in twinBASIC.

Like operator

This one is a big issue for converting existing code; hopefully, it gets implemented soon.

Debug.Print syntax won't allow commas or semi-colons
Mid statement (not the function; did you know there was a statement?)
RSet statement
GoSub statement
DefType syntax

The GitHub project

Wayne has created a GitHub project to track bugs and feature requests. twinBASIC itself is not open-source; however, GitHub provides an easy and familiar way for developers to report issues as they come up.

Wayne created a couple of templates to help maintain the quality of reported issues:

To track progress on the features that are known limitations, use this search string:

is:issue "limitation with the preview release"

The VS Code Changelog

As Wayne and his team address issues, they reference them in the twinBASIC Changelog tab of the VS Code extension:

Bug fixes in twinBASIC's Changelog now tie back to GitHub.

My Advice

I recommend you hold off on trying to convert large blocks of existing VBA code to twinBASIC until some more of the core functionality is in place. In the meantime, play around with the development environment by writing code that takes advantage of the new features of the language.

Image by Hany Alashkar from Pixabay