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.
Here are some links to get involved with the project:
- Custom twinBASIC IDE Installation Guide (NOTE: the twinBASIC VSCode extension is under a feature freeze until 2023)
- GitHub Issue Tracker (report bugs)
- twinBASIC Discord Server (chat about the project)
- twinBASIC/VBx LinkedIn Group
Roadmap (and v1 Release Date) Updated
Note from Wayne in Discord:
As many of you have probably already realized, finalizing the initial ActiveX/UserControls support has taken up much more time than originally anticipated. I've updated the roadmap today (https://github.com/twinbasic/twinbasic/issues/335). Regrettably, I've had to push most of the roadmap back 3 months due to this. It has become obvious that it simply would not have been possible to produce a polished version 1 product by the original tentative 9th April date. Thank you all for your support as always.
As part of this update, Wayne added the following items to the Q1 2023 roadmap:
- Complete the missing App object methods (VB6 App object not supported #143)
- Add the missing features to the new IDE, e.g. rename-refactoring and Test Explorer
Also, the projected version 1 release date was changed from April 9, 2023, to July 3, 2023.
New UserControl Events Implemented
As of BETA 235, the following UserControl properties and events have been implemented:
Terminateevent (as of BETA 234)
.CanGetFocusproperty (initial support)
LostFocusevents (initial support)
IOleInPlaceActiveObjectinterface (initial support)
Improvements to Form Modal Dialogs
As of BETA 233, "form modal dialogs now have titlebars and can be moved via dragging the titlebar."
ActiveX Support Returning Soon
As noted in the Changelog section below, support for building ActiveX controls has been broken since BETA build 202. Critically, this includes creating ToolWindows as used in most VBE addins. The good news is that this long-standing bug is set to be fixed soon. As Wayne notes,
[B]uilding ActiveX controls is known to be broken in these releases. The next release is a major release for ActiveX support, and so this will be working again very soon.
Wayne elaborated further in Discord on 2023-01-21:
Just giving you folks a heads-up; there won't be an update for a few days as I'm knee deep in finalizing ActiveX/UserControls support. I've now got our tB-generated Ax controls working in VB6 which is helping clarify a few things so that we get behaviour much closer to the VBx implementations.
Around the Web
Shell Browser and Shell Tree Controls
This repository contains a twinBASIC x86/x64 compatible port of my shell controls, ucShellBrowse and ucShellTree.
See the original threads for a full list of all of the extensive features of these controls:
• [VB6] ucShellBrowse: A modern replacement for Drive/FileList w/ extensive features
• [VB6] ucShellTree - Full-featured Shell Tree UserControl
These are beta versions.
There's still some work to do in twinBASIC to complete user control support, but it's now far enough along even a massively complex control like ucShellBrowse can run. Notably, there's numerous issues with sizing and scaling. The demos included in this repository have worked around them as best I could. Also, I haven't exhaustively tested all features. Please don't hestitate to create an issue for any bugs you encounter.
RegShellWindow v2.1 - Shell Window Registration
Yet another of fafalone's 64-bit compatible twinBASIC ports from VB6 originals is available on GitHub. RegShellWindow lets you "[r]egister your app as displaying a path for SHOpenFolderAndSelectItems etc."
This twinBASIC demo project comes from Ben Clothier and is also available on GitHub:
This is a demonstration project showing how twinBASIC can host a .NET 7. Though .NET does support COM activation where the hosting is automatically handled by the internal implementation of the generated
.comhost.dllfile, this simply show how the hosting can be done manually and controlled by twinBASIC without any COM registration required. Furthermore, the project loads a WPF Page UI control into the window provided by the twinBASIC, demonstrating how to host WPF directly by twinBASIC.
Bind variable in
With block to a name
This language design suggestion comes from Greedquest, who writes:
Withblocks like context managers to ensure a temporary object gets cleaned up when I'm done with it. With a regular
Withblock I often find I would like to refer to the variable itself particularly when passing it to some sub-function.
He suggests the following syntax (along with a few alternatives which you can see via the link above):
With New Excel.Application Alias app app.Name End With With CreateObject("Excel.Application") Alias app app.Name End With
I'm torn on the suggestion as it amounts to syntactic sugar, a problem that I feel has plagued C# over the years. On the other hand, I've found myself in the exact position that Greedquest describes on many occasions. This feature is something I would definitely take advantage of.
After giving it some thought, I think I'd like to see this syntax as a package deal with block-level scoping. They're different concepts, but closely related. This makes the most sense if we use Ben Clothier's suggestion to re-use the obscure
Local VBA keyword for block-level scope.
Here's my recommendation for an alternative syntax to Greedquest's original post:
With New Excel.Application Local app app.Name End With With CreateObject("Excel.Application") Local app app.Name End With
Local is a VBx keyword, we don't have to worry about breaking backward compatibility of existing code. However, since it's such an obscure keyword, there is very little existing documentation for it. Thus, the twinBASIC documentation for the
Local keyword would not be competing with existing VBx documentation, which would make its new usage much more discoverable for new users.
3rd Party Controls Wishlist
Over on GitHub, user PDBNZ posted a wish list for community/commercial third-party twinBASIC controls. His list, in no particular order, is:
- Ribbon control
- Grid with all the bells and whistles
- Chart control
- Reporting component
- Pivot/OLAP control
fafalone offered some possible solutions:
There's already some great grid and ribbon controls for VB6, these should mostly work unmodified in tB in x86 mode at least, or with a minor rework to swap out the assembly thunk based and other incompatible self-subclassing methods you find in a lot of UCs.
If they're popular enough, most are released under licenses that would allow us to make an x64-compatible port if the author isn't around anymore (or is and gives permission). It's not really that difficult at all, having done both this and swapping subclassing for my own large, complex controls, just a bit time consuming.
Here are the updates from the past week. You can also find this information by visiting the GitHub twinBASIC Releases page.
WARNING: The following two issues are present in BETA builds 202 - 237 (the latest build as of publication):
- building ActiveX controls is known to be broken in these builds. Use BETA 201 instead for that feature.
- there are known memory leaks in these versions, so memory usage will be higher than normal
- fixed: repainting of lightweight controls when AutoRedraw = True [ sokinkeso, discord ]
- fixed: form designer IPerPropertyBrowsing dropdown order (e.g. VBCCR.MousePointer)
- fixed: ActiveX z-ordering issue [ fafalone, discord ]
- fixed: (regression) UserControl properties sometimes not deserialized on time [ fafalone, discord ]
- improved: form modal dialogs now have titlebars and can be moved via dragging the titlebar
- fixed: UserControl.Terminate event is now firing
- fixed: Set-assignment reference leak when an error occured setting a WithEvents variable, in some instances
- fixed: (regression) Unload statement could crash at runtime
- added: initial Date/Date$/Time/Time$ property-let implementations [ https://github.com/https://github.com//issues/421 ]
- fixed: improved stability around form destruction to prevent potential crashes due to race conditions
- fixed: UserControl.Terminate event marked as unimplemented, despite being implemented
- added: warning TB0011 UseOfLegacyDateTimePropLet [ https://github.com//issues/421#issuecomment-1384261226 ]
- added: initial UserControl.CanGetFocus / GotFocus event / LostFocus event support
- added: initial ActiveXExtender.GotFocus / LostFocus events support
- added: UserControl.Click / DblClick events support
- added: UserControl.MouseDown / MouseMove / MouseUp events support
- added: UserControl.KeyDown / KeyPress / KeyUp events support
- added: UserControl.KeyPreview support
- added: initial support for IOleInPlaceActiveObject interface in UserControl
- fixed: ActiveXExtender now filters the messages passed to IOleIPAO.TranslateAccelerator, so that only WM_KEYDOWN/UP and WM_SYSKEYDOWN/UP pass through it
- fixed: importing a VBP would fail from a network share
- improved: during VBP import, references with relative paths are now changed to absolute paths, with an import warning
- fixed: UserControl.GotFocus/EnterFocus events firing during control instantiation
- fixed: Select and With statements could cause compiler crash if used inside generics
- fixed: ComboBox and DriveListBox potential crash during form destruction, due to race condition in removing subclassing