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.
Importing VB6 Project Files (*.vbp)
twinBASIC now allows import of Visual Basic 6 project files (*.vbp).
To get to this option, you need to click on the large twinBASIC icon on the left sidebar of the VS Code window. The option is currently not available from the F1 menu, but I assume that's just an oversight.
Since VB forms are not supported yet, any form files will fail to import. This will be apparent from the log file that is created during the import process:
This new feature will make it much easier to convert existing VB6 ActiveX libraries to run under twinBASIC.
New MsgBox Option: vbCancelTryAgainContinue
You can now display "Try Again" and "Continue" buttons in the built-in twinBASIC message box.
To do this, use the new
vbCancelTryAgainContinue enum. To check the return values, use the constants
vbTryAgain (10) and
Text Encoding Feature Now Uses Constants Not Strings
In last week's update, I wrote about twinBASIC adding text encoding support for several file I/O statements. At the time, the experimental feature relied on strings to identify the various code pages, such as
Encoding syntax still expects a String variable, but Wayne has introduced a set of constants for common code pages:
As you can see in the screenshot below, these constants are not enumerated long integers, rather they are simply a safer way to refer to common code pages. Why are they safer than using strings directly? Because a typo in the constant will result in a compile error, while a type in the string will result in a runtime error. And compile errors are cheaper and easier to fix than runtime errors.
App.Path and App.EXEName
App.Path returns the folder where the application is running from.
App.EXEName returns the application executable's file name.
These new functions are available as of version 0.13.34.
Why Can't We Be Friends?
Because the Friend keyword was unsupported in twinBASIC...until now!
As of v0.13.32, the Friend access modifier is now supported on class members.
Improved Runtime Error Messages
One of the big day-to-day stumbling blocks of developing in twinBASIC is the lack of specificity in many of its error messages. That's beginning to change now, as external COM errors will return more useful error messages:
Exception has occurred.
The Microsoft Access database engine could not find the object 'SomeTable'. Make sure the object exists and that you spell its name and the path name correctly. If 'SomeTable' is not a local object, check your network connection or contact the server administrator.
- Error Number: -2147217S65 (&HS0040E37)
[Restricted] and [Hidden] Attributes
Version 0.13.45 now supports adding [Restricted] and [Hidden] attributes to:
- Class types
These attributes only affect the behavior of the generated type library when creating COM add-ins from twinBASIC.
Around the Web
WebAssembly Support on the (Distant) Horizon
Subscribe to the GitHub issue if you're curious about progress on this particular topic:
[A]s twinBASIC expands into cross-platform, should it consider WebAssembly?
Wayne seems to be on board...
Yes, I totally agree, this should be considered. This has been in the back of my mind for some time.
Spirited Discussion About the
a += 1 Syntax
Over at VBForums, a discussion about the proposed Array() statement syntax quickly morphed into a broader discussion about what the appropriate mentality should be for a VBx replacement language (along with dozens of posts about the inclusion of the
a += 1 syntax). The discussion broke down into roughly three camps:
- There should be laser focus on the 100% compatibility goal until its met
- The language should avoid adding too many features to keep its beginner appeal
- To succeed, the language must provide features available in other modern languages
All three camps have solid arguments to make. In my mind, though, following any of the above approaches to the extreme would be a recipe for disaster. A big part of making twinBASIC succeed in the long term is to weigh the competing interests of the three camps above and strike an appropriate balance.
I think Wayne's approach with the GitHub issues page has been a massive success in this regard. The discussions around new feature proposals bring together many brillliant minds. This group effort results in implementations that are better than if Wayne was working in isolation.
At the same time, having a single person making final decisions for a new language is just as critical to its success. It's incredibly difficult to get a group of people to agree on–and adhere to–a single vision for any project. There is certainly precedence in this model, as the Python programming language was originally built and guided by a single person, Guido van Rossum (affectionately known in that community as BDFL).
Wayne eventually weighed in with his thoughts:
With twinBASIC the #1 priority is, and always has been, backwards compatibility. ... Along with the goal of full backwards compatibility, we are of course adding new features to the language... Many will argue that you can add new features later, but I can assure you: it's just not that easy!
If you want to help steer the future direction of twinBASIC, I can only encourage you to please come over to our github issue tracker and join in with the discussions. If you've got ideas on what you'd like to see happen, please create a feature-request issue, describing your proposal. ... We're a friendly bunch, and I personally really want to hear from you!
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.13.46, 19th December 2021]
- fixed: linker crash on building the CustomControls sample project due to attribute changes made in v0.13.44/45 [ https://github.com/WaynePhillipsEA/twinbasic/issues/580 ]
[v0.13.45, 19th December 2021]
- improved: Restricted and Hidden attributes now available on fields and types [ https://github.com/WaynePhillipsEA/twinbasic/issues/25#issuecomment-997215862 ]
- fixed: regression involving constants evaluation when no datatype is specified in v0.13.43/44 [ https://github.com/WaynePhillipsEA/twinbasic/issues/578 ]
- fixed: HRESULTs with a facility of 10 now correctly translate to a VBx compatible Err.Number [ https://github.com/WaynePhillipsEA/twinbasic/issues/56#issuecomment-997150061 ]
- fixed: crash when trying to call Private members alongside the WithDispatchForwarding feature [ https://github.com/WaynePhillipsEA/twinbasic/issues/576 ]
[v0.13.44, 18th December 2021]
- improved: Sample 4 and Sample 5 (VBE/Access/Excel Addins) no longer require .reg files, using the DllRegisterServer callbacks instead [ https://github.com/WaynePhillipsEA/twinbasic/issues/576 ]
[v0.13.43, 18th December 2021]
- added: Restricted attribute for marking procedure members as restricted in COM type libraries [ https://github.com/WaynePhillipsEA/twinbasic/issues/25#issuecomment-997137193 ]
- added: Hidden attribute for marking procedure members as restricted in COM type libraries [ https://github.com/WaynePhillipsEA/twinbasic/issues/25#issuecomment-997137193 ]
- improved: internal handling of Const values, preventing a compiler crash in some instances
[v0.13.42, 17th December 2021]
- improved: removed dependency on SetDllDirectory API in EXE/DLL builds if SetDllDirectory attribute is not used [ https://github.com/WaynePhillipsEA/twinbasic/issues/455 ]
- improved: errors from external COM objects are now reported properly [ https://github.com/WaynePhillipsEA/twinbasic/issues/56 ]
[v0.13.41, 17th December 2021]
- added: SetDllDirectory attribute for Declare statements to allow for transitive DLL loading [ https://github.com/WaynePhillipsEA/twinbasic/issues/455 ]
[v0.13.40, 16th December 2021]
- improved: custom DLLs are now loaded via LoadLibary on-demand instead of via the OS PE Loader, to match VBx behaviour [ https://github.com/WaynePhillipsEA/twinbasic/issues/372, https://github.com/WaynePhillipsEA/twinbasic/issues/284 ]
[v0.13.39, 15th December 2021]
- improved: restricted the v0.13.38 fix to just the new 'Continue' keyword [ https://github.com/WaynePhillipsEA/twinbasic/issues/563#issuecomment-994203718 ]
[v0.13.38, 15th December 2021]
- improved: identification of line labels now takes precedence over keywords, allowing 'Continue' to be used as a regular line label [ https://github.com/WaynePhillipsEA/twinbasic/issues/563#issuecomment-994203718 ]
[v0.13.37, 15th December 2021]
- fixed: handling of implemented Friend members causing bogus 'duplicate implementation of member' error
- fixed: type-library creation now outputs original typedefs, rather than the resolved types [ https://github.com/WaynePhillipsEA/twinbasic/issues/536#issuecomment-994621676 ]
- added: VbMsgBoxStyle.vbCancelTryAgainContinue [ https://github.com/WaynePhillipsEA/twinbasic/issues/568 ]
- added: VbMsgBoxResult.vbTryAgain [ https://github.com/WaynePhillipsEA/twinbasic/issues/568 ]
- added: VbMsgBoxResult.vbContinue [ https://github.com/WaynePhillipsEA/twinbasic/issues/568 ]
[v0.13.36, 15th December 2021]
- added: 'Import from Visual Basic ...' option in the twinBASIC activity bar, allowing importing from VBP projects [ https://github.com/WaynePhillipsEA/twinbasic/issues/303 ]
[v0.13.35, 14th December 2021]
- fixed: MsgBox regression [ https://github.com/WaynePhillipsEA/twinbasic/issues/566 ]
[v0.13.34, 14th December 2021]
- added: App.Path implementation
- added: App.EXEName implementation
- improved: LongLong will now not auto-coerce to narrower types (Byte, Integer, Long, Currency), matching VBA7 behaviour [ https://github.com/WaynePhillipsEA/twinbasic/issues/279#issuecomment-981573954 ]
- improved: intellisense for 'Set = |' will now also include 'Nothing' as an option alongside the existing 'New ' where appropriate
- fixed: fixed length strings now allowed in Redim statements (e.g. 'Redim myVar(2) As String * 5')
- fixed: semantic highlighting glitch when Redim is used to also declare the variable that it is re-dimensioning, the variable symbol would be white
[v0.13.33, 13th December 2021]
- improved: symbols surrounded in square brackets now never match to built-in keywords [ https://github.com/WaynePhillipsEA/twinbasic/issues/563 ]
- fixed: debugging of procedures with names containing embedded double-quotes was failing [ https://github.com/WaynePhillipsEA/twinbasic/issues/494 ]
[v0.13.32, 13th December 2021]
- added: VBA.TextEncodingConstants module that includes constants for the common supported codepages and aliases for use with Open # Encoding syntax [ https://github.com/WaynePhillipsEA/twinbasic/issues/555#issuecomment-991676810 ]
- improved: Open # syntax now shows intellisense for the Encoding syntax extension [ https://github.com/WaynePhillipsEA/twinbasic/issues/555 ]
- improved: Friend access modifiers so that the symbols are not exposed publicly via the type library [ https://github.com/WaynePhillipsEA/twinbasic/issues/14 ]
- fixed: datatypes LPWSTR and LPSTR (c-strings) are now supported for function arguments defined in type-libraries [ https://github.com/WaynePhillipsEA/twinbasic/issues/381 ]
[v0.13.31, 13th December 2021]
- fixed: more issues relating to double-quotes in identifiers, causing LSP/DAP failures [ https://github.com/WaynePhillipsEA/twinbasic/issues/545 ]
- fixed: one of the internal structure offsets was not 64-bit aware, causing error propagation to COM callers to hard crash. 64-bit only. [ https://github.com/WaynePhillipsEA/twinbasic/issues/560 ]