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.
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:
If I run the same code in VBA, my carelessness becomes obvious:
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:
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.
In VBA, you can separate strings in the Debug.Print statement using semicolons and commas. That syntax is not yet supported in twinBASIC:
Built-in file operations
The File Statements are
The FileSystem functions are
The FileSystem subroutines are
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
- 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.execan'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:
- Like operator
- 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:
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.