twinBASIC Update: August 1, 2021

Highlights include VSCode CodeLens support, compiler warnings, VB_GlobalNameSpace support, and twinBASIC's debut on stackoverflow.

twinBASIC Update: August 1, 2021

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.


CodeLens Support Introduced

From the feature announcement on GitHub:

CodeLens allows us to provide extra information (and actions) inline in the code editor.  Initially we've got this one for no-argument procedures in standard modules:

Compiler Warnings

twinBASIC now has support for compiler warnings.  Each warning has three possible project-level settings:

  • Error: code won't compile
  • Warning [default]: warning shown during compilation
  • Ignore: code compiles; no message shown

You can override these settings at the class, module, or procedure level using the following attributes:

[ EnforceWarnings(TBxxxx) ]
[ EnforceErrors(TBxxxx) ]
[ IgnoreWarnings(TBxxxx) ]

The warnings can be found in the project Settings page under the heading, Compiler Warnings.  So far there are three warnings (see below).  To suggest others, head to the Compiler Warnings issue page on GitHub.

VB_GlobalNameSpace Support

From the feature announcement on GitHub:

This feature allows class members to be called implicitly on a predeclared class, without qualifying the call with the class name. Many of the Office applications use this feature in their typelibraries. For example, in Access you can do this:
MsgBox Access.Name  ' Access is the type library identifier.  
                    '    this routes through to the predeclared 
                    '    Application class, via Application.Name

MsgBox Name   ' Same as above, showing you 
              '    don't need the type library identifier.
This is now supported as of v0.10.3790, so for example the two examples [above] work as expected if a COM reference to the Access type library is set.  Additionally, we now have a [AppObject] attribute, as pictured [below], to allow unqualified access to predeclared object members, matching the legacy VB6 VB_GlobalNameSpace attribute (which is also supported).

Around the Web

twinBASIC Debuts on StackOverflow

The first question referencing twinBASIC appeared on StackOverflow on June 25.  Andrew Mansell pointed out the question over on the GitHub issue tracker.

I added a twinBASIC tag to the question and filled in some preliminary information about the twinBASIC project in the tag wiki.


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.3790, 1st August 2021]

[v0.10.3744, 1st August 2021]

[v0.10.3697, 31st July 2021]

[v0.10.3685, 30th July 2021]

[v0.10.3664, 30th July 2021]

[v0.10.3613, 29th July 2021]

[v0.10.3604, 29th July 2021]

  • added: internal framework for supporting compiler warnings [ ]
  • added: compiler warning TB0001: use of legacy DefType statements is strongly discouraged
  • added: compiler warning TB0002: this variable has been auto-declared by the compiler due to Option Explicit being OFF

[v0.10.3511, 27th July 2021]

[v0.10.3482, 26th July 2021]