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.
There were some major developments in the twinBASIC world this week, including support for external version control; the official launch of the prettifier (now enabled by default); and support for resources and visual styles via manifest files.
Version Control Support!!!!
This one is a huge deal for me. The lack of usable version control was a major issue. It kept me from really diving in and putting twinBASIC through its paces. twinBASIC now supports external version control via
I call it external version control because it is not yet integrated into VS Code. The import and export flags will simply extract the text files embedded in the .twinproj container files into plain, UTF-8 text files in a destination folder location. The extracted text files can then be diffed, merged, or committed in the version control platform of your choice (Git, Mercurial, SVN, etc.).
The catch is that you need to pass the
export flags to the twinBASIC executable. The executable is buried in a versioned subfolder of the VS Code extensions folder. This means that the location of the twinBASIC exe will change every time there is a new release of twinBASIC (which happens more than once a day on average).
To address this issue, I built a batch file that automatically finds and runs the latest twinBASIC executable. As long as you have the twinBASIC VS Code extension installed, the batch file should just work.
While VS Code integrated version control is not yet available, it is on the project roadmap.
Code Prettifier Matures
Speaking of version control, one thing that gives twinBASIC a huge leg up on VBA in terms of version control is its improved implementation of identifier letter casing.
Whereas VBA forces global updates with complete disregard for identifier scope, twinBASIC uses intelligent letter casing updates. The authoritative letter casing occurs within the declaration line. All other lines of code are then updated to match.
This feature is known as the code "prettifier" in twinBASIC, and as of v0.10.2477, it is enabled by default.
Here's Wayne's announcement from the relevant GitHub issue:
You can now create an embedded manifest in twinBASIC very easily. Just create a MANIFEST folder in the Resources folder, and inside it create a new file called #1.xml. Copy and paste the manifest from the following txt file.
As soon as you build your EXE with the manifest embedded you'll now see that visual styles are applied, e.g. to MsgBox calls.
The next tB update will include a VS code command for generating this manifest file for you.
This currently doesn't affect code running in the IDE, since the manifest would need to be applied to the compiler EXE. However, tB will soon read the manifest in your resource data, and turn ON/OFF visual styles for you, for code running in the IDE, based on that manifest file.
Shortly after the initial announcement, Wayne announced an automated process for creating the Resource Manifest file. The copy-paste step from above is no longer necessary:
We now have a VS Code command of 'twinBASIC: Create Resource Manifest (Visual Styles)' available by right-clicking on the Resources folder, or via the command palette (F1).
Around the Web
Support for EXE/DLL embedded resources
Wayne started a new discussion around how best to implement resource embedding:
The Sample 5 project has been updated to show how to create a ribbon with an embedded image for the button.
Join the discussion here: Support for EXE/DLL embedded resources
Raise all Terminate events on Stop?
There was a new comment on a discussion from the early days of the twinBASIC release:
One option - this is what python does - is to have a soft stop (interrupt) and a hard stop (suspend). For a python terminal app,
ctrl+craises a KeyboardInterrupt Exception which can be caught and handled, and is no worse than any other exception. Meanwhile
ctrl+zsuspends the process without any other code running, pull the rug out like stop button/end. The KeyboardInterrupt Exception also derives from a different base class to the others so it must be caught explicitly, meaning it generally does a pretty good job of bringing down a program safely.
Join the discussion here: To raise all Terminate events on Stop
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.2799, 27th June 2021]
- added: vscode extension command 'twinBASIC: Create Resource Manifest (Visual Styles)', available via F1 and via right-click on Resources folder [ https://github.com/WaynePhillipsEA/twinbasic/issues/68 ]
- fixed: TypeOf-Is datatype validation now occurs at the resolver stage rather than code-gen stage [ https://github.com/WaynePhillipsEA/twinbasic/issues/243 ]
[v0.10.2781, 26th June 2021]
- fixed: LoadResPicture now returns IPictureDisp (rather than generic Object) when stdole library is referenced, to give better intellisense [ https://github.com/WaynePhillipsEA/twinbasic/issues/240 ]
[v0.10.2780, 26th June 2021]
- fixed: spaces in the path to the twinBASIC executable causing issues since v0.10.2600 [ https://github.com/WaynePhillipsEA/twinbasic/issues/241 ]
- fixed: changed LoadResPicture signature to closer match VB [ https://github.com/WaynePhillipsEA/twinbasic/issues/240 ]
- fixed: LoadResPicture was binding to interface IPicture rather than IPictureDisp, causing issues if the object was not first cast to the appropriate type [ https://github.com/WaynePhillipsEA/twinbasic/issues/240 ]
- fixed: added DWORD alignment to embedded resource data elements, without affecting data element sizes [ https://github.com/WaynePhillipsEA/twinbasic/issues/68 ]
[v0.10.2773, 25th June 2021]
- added: support for resources, including support for LoadResData and LoadResPicture [ https://github.com/WaynePhillipsEA/twinbasic/discussions/238, https://github.com/WaynePhillipsEA/twinbasic/issues/68 ]
[v0.10.2600, 23rd June 2021]
- added: command-line arguments to the compiler for extracting and rebuilding .twinproj files [ https://github.com/WaynePhillipsEA/twinbasic/issues/232 ]
[v0.10.2532, 22nd June 2021]
- fixed: off-by-one error in buffered output length calculation, causing Debug.Print zones to be aligned incorrectly [ https://github.com/WaynePhillipsEA/twinbasic/issues/233 ]
- fixed: project-level compiler conditional arguments are now honoured [ https://github.com/WaynePhillipsEA/twinbasic/issues/229 ]
[v0.10.2477, 22nd June 2021]
- improved: rewrote the prettifier, removed experimental status and made it default to ON
- fixed: double-free of memory when encountering a For-block without corresponding Next closure