twinBASIC Update: February 13, 2022

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.

Here are some links to get involved with the project:

Highlights

Settings Filter Bar

Wayne added a filter bar to the Settings area to make it easier to find and change project settings:

Added a Predeclared Global Class

As of version 0.14.10, the "App / Clipboard / LoadResPicture / LoadResData / LoadResString [have been] moved to the Global predeclared class, as per VB6."

The App class itself is still incomplete, as it currently implements only the following properties:

  • Build
  • EXEName
  • hlnstance
  • IsInIDE
  • Major
  • Minor
  • Path
  • Revision
  • ThreadID

To get updates on the status of the remaining App properties, follow GitHub issue 143, VB6 App object not supported.

Around the Web

Error Handling Settings When Debugging twinBASIC

Kr00l started a discussion about how twinBASIC should replicate the "Error Trapping" IDE options from VBx:

Here's Wayne's response:

At the moment, the tB debugger is in a sort of mixed mode.... "Break On Unhandled Errors AND in Class Modules".  This is what I consider to be a more natural way of debugging... since it more accurately reflects what happens when you compile to an EXE/DLL.   For example, if we compile your OERN example in VB6 to an EXE, the error does propagate back to Main() and the code does continue beyond the .Test call as expected without interruption... so the current tB debugging behaviour matches that.

That said, I do agree that we should still offer Break on Unhandled Errors and Break in Class Modules modes of course.

Ben Clothier recommended adding support for a debugger-specific attribute as this setting only changes behavior of the code while running in the debugger and not at runtime:

I'm thinking it will be clearer to decorate with something like:

[DebuggerBehavior(BreakOnAllErrors)]
[DebuggerBehavior(BreakInClassModules)]
[DebuggerBehavior(BreakOnUnhandledError)]
[DebuggerBehavior(MatchRuntimeBehavior)]

No More Separate Update Needed for the WinForms Controls Package

Wayne dropped the following nugget of information in the twinBASIC Discord server:

[Starting February 14, 2022], the Windows controls package and the CustomControlsPackage will be included as part of the compiler deployment.  This means that when we release a new version of the compiler, you won't need to do anything in your projects in order to get the latest up-to-date version of the forms implementation; your projects will automatically reference the latest version that shipped with the compiler.

This is a welcome addition, as it removes a manual step that was previously required if you wanted to see updates in the twinBASIC WinForms controls package.

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.14.18, 12th February 2022]

[v0.14.17, 11th February 2022]

  • added: Global.LoadPicture method

[v0.14.16, 11th February 2022]

[v0.14.15, 11th February 2022]

[v0.14.14, 10th February 2022]

[v0.14.13, 10th February 2022]

[v0.14.12, 10th February 2022]

[v0.14.11, 9th February 2022]

[v0.14.10, 9th February 2022]

[v0.14.9, 8th February 2022]

[v0.14.8, 7th February 2022]