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.
Last week was a slow week with no published twinBASIC updates. This week made up for that. There were eight (!) releases this week with a host of improvements and bug fixes.
Improved stability and memory management
After 17 days between releases, version 0.10.220 included a:
"major overhaul of internal compiler memory management. work still ongoing, but drastic improvements for larger projects in this update"
"Internal compiler memory management" is to a programming language what the foundation is to a house. It's something you never see and never think about...unless it's not done right.
Not the sexiest improvement, but an important one nonetheless.
Optional keyword is ... optional
On the other end of the spectrum is this change in syntax that makes the
Optional keyword optional (how meta is that!), so long as you provide an explicit default value.
So, now in addition to this...
...you can also do this...
Of course, in keeping with its backward compatibility promise, the traditional approach of including the
Optional keyword will always be supported.
Debugger command line arguments
You can now set command-line arguments within Build Configurations:
Around the Web
There is a Discussions page at the twinBASIC GitHub project site where you can engage with Wayne Phillips on evolving aspects of twinBASIC. I'll highlight a few of the conversations taking place there.
Project files should be human readable
Andrew Mansell began a discussion about the decision to use a binary container file (.twinproj) as opposed to plain text files. His point–one that is near and dear to my heart–is that binary files don't play nicely with modern version control systems.
Wayne countered that the .twinproj files are not typical binary files, but rather container files. They are more analogous to .zip files. Wayne cites several reasons for making this choice. Most importantly, though, he recognizes the need to support version control, both inside and outside of VS Code (emphasis mine):
"We will be providing a simple extraction tool for twinproj files, so that you can do SCC outside of VS code if you wish, but ultimately the main aim is to offer SCC inside VS code (which doesn't actually see the twinproj file itself, only the contents via its virtual file system)."
Lest you worry about whether you will be able to reconstitute a .twinproj file from the exported source code, Wayne assures us that such a feature is also forthcoming:
"tB will be able to reconstruct the twinproj file fully from the repository. At the moment, things like breakpoints are stored as meta data rather than actual files in the virtual filesystem, but this will be changing soon so that literally everything will be able to be cloned to/from a repository."
If you're interested in version control, I recommend reading the entire exchange.
GUI Coming Soon!
Okay, "soon" is probably the wrong word. Perhaps "GUI Coming Next" would be more accurate.
In any case, Wayne announced that he has settled on an approach for GUI support:
"In other news, I thought it worth mentioning here that I've now decided on the approach for GUI support. twinBASIC will eventually offer two types of GUI forms. One for Windows-only, which is fully backwards compatible with VB6, and a second type of form that supports cross-platform but is not 100% backwards compatible. I'll be making every effort to make the cross-platform forms 'feel' like VB6 forms as much as possible, and the form designer will be shared between them both."
There are some very Windows-specific features built into the VB6 GUI platform, including Windows handles and ActiveX controls. Those things will be supported for backwards compatibility. For cross-platform projects, you will need to convert existing forms to their cross-platform equivalent. It will be interesting to see how much–if at all–that process can be automated.
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.655, 29th May 2021]
- added: support for RSet statement
[v0.10.621, 29th May 2021]
- fixed: With blocks not supporting nested UDTs [ https://github.com/WaynePhillipsEA/twinbasic/issues/149 ]
- fixed: AscB() was not working if the length of the input string was a single byte (i.e. a half unicode character)
- fixed: LSet not working with strings, and UDT fixed length string members [ https://github.com/WaynePhillipsEA/twinbasic/issues/155 ]
[v0.10.580, 28th May 2021]
- fixed: Debug.? syntax now allowed [ https://github.com/WaynePhillipsEA/twinbasic/issues/166 ]
[v0.10.575, 28th May 2021]
- fixed: restricted use of Print/? (with implicit Debug) to just inside the debug console, much like VBA [ https://github.com/WaynePhillipsEA/twinbasic/issues/166 ]
- fixed: regression where procedures with compilation errors were being allowed to be partially executed
- fixed: allow for the legacy 'On Local Error' form [ https://github.com/WaynePhillipsEA/twinbasic/issues/140 ]
- removed: old (temporary) WithDispatchForwarding syntax, in favour of the new WithDispatchForwarding attribute [ https://github.com/WaynePhillipsEA/twinbasic/issues/110 ]
[v0.10.540, 28th May 2021]
- improved: the Optional keyword for parameters is now inferred automatically if a default value has been provided, making the Optional keyword, ahem, Optional
- fixed: Implements feature now validates that all derived members are to be implemented [ https://github.com/WaynePhillipsEA/twinbasic/issues/165 ]
- fixed: further refined the Optional and ParamArray keyword validation [ https://github.com/WaynePhillipsEA/twinbasic/issues/161 ]
[v0.10.509, 28th May 2021]
- improved: more strict grammar rules around ByVal / ByRef / Optional / ParamArray attributes [ https://github.com/WaynePhillipsEA/twinbasic/issues/161 ]
- added: build configuration setting "runtimeCommandLineArguments" for allowing to customize the command line arguments passed to the debugged executable [ https://github.com/WaynePhillipsEA/twinbasic/issues/160 ]
- fixed: debugger crash when expanding a zero-length array in the locals window [ https://github.com/WaynePhillipsEA/twinbasic/issues/156 ]
- fixed: now considers the non-extensible flag during compilation [ https://github.com/WaynePhillipsEA/twinbasic/issues/142 ]
- fixed: private scoping issue involving enum value evaluation [ https://github.com/WaynePhillipsEA/twinbasic/issues/150 ]
- fixed: parser bug involving single line If-Then-Else and Let/Set/LSet statements [ https://github.com/WaynePhillipsEA/twinbasic/issues/148 ]
[v0.10.313, 27th May 2021]
- improved: stability
- fixed: implied maximum alignment of non-typelibrary UDT members, to match VB [ https://github.com/WaynePhillipsEA/twinbasic/issues/136 ]
- fixed: unicode-to-ANSI conversions handling of vbNullString [ https://github.com/WaynePhillipsEA/twinbasic/issues/141 ]
- fixed: compiler crash involving With block dot accessors [ https://github.com/WaynePhillipsEA/twinbasic/issues/151 ]
- fixed: incorrect codegen for LBound/UBound on ByRef variants [ https://github.com/WaynePhillipsEA/twinbasic/issues/157 ]
- fixed: debugger locals window was not showing values of fixed-length strings [ https://github.com/WaynePhillipsEA/twinbasic/issues/152 ]
[v0.10.220, 27th May 2021]
- improved: removed the single source file limitation
- improved: 'add component' UX from the twinBASIC VS code panel
- improved: major overhaul of internal compiler memory management. work still ongoing, but drastic improvements for larger projects in this update
- fixed: caching issues
- lots of (minor) internal performance and stability improvements