twinBASIC Update: December 19, 2021

Mike Wolfe -

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.

Highlights

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 vbContinue (11).

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 "utf-8 BOM".

The tB 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.

The Path and ExeName for the sample CustomControlsProject running on my PC.

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:

  • Procedures
  • Class types
  • Fields

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:

  1. There should be laser focus on the 100% compatibility goal until its met
  2. The language should avoid adding too many features to keep its beginner appeal
  3. 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!

Changelog

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]

[v0.13.45, 19th December 2021]

[v0.13.44, 18th December 2021]

[v0.13.43, 18th December 2021]

[v0.13.42, 17th December 2021]

[v0.13.41, 17th December 2021]

[v0.13.40, 16th December 2021]

[v0.13.39, 15th December 2021]

[v0.13.38, 15th December 2021]

[v0.13.37, 15th December 2021]

[v0.13.36, 15th December 2021]

[v0.13.35, 14th December 2021]

[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]

[v0.13.32, 13th December 2021]

[v0.13.31, 13th December 2021]