twinBASIC Weekly Update

twinBASIC Update: September 12, 2021

Highlights include VS Code Extensibility, RGB extraction functions, dropping Finalize(), and a discussion regarding potential typedef support.

Mike Wolfe

• 6 min read
twinBASIC Update: September 12, 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.

Highlights

VS Code Extensibility

Exciting news that opens up a whole realm of new possibilities in the form of community-created addins for twinBASIC:

As of v0.10.5725, we now have some extra VS Code extensibility things of interest.  Before reading on, note that this is EXPERIMENTAL and the API is highly subject to change, and errors are not yet propagated from VS Code back to the twinbasic code.  Consider this just a sneak peek at what me might be able to do in the future in this regard...

RGB Extraction Functions

The VBA.Information library includes an RGB function that returns a Long integer representing an RGB color value.  However, there are no built-in functions to extract an individual color value from an RGB color value.

As of v0.10.5494, twinBASIC supports these extraction functions.

In addition, you can also create RGB color values with an Alpha transparency layer using the newly added RGBA function.

Yellow with a 50% transparency

There is a corresponding RGBA_A() extraction function to pull the alpha transparency value:

The RGB_R/G/B() extraction functions work with RGBA values (there are no separate RGBA_R/G/B() functions):

Support for Finalize() dropped for backward compatibility

As a counterpart to the constructor procedure, Sub New(), tB included support for a corresponding destructor procedure, Sub Finalize().  The problem is that Sub Finalize() could potentially break backwards compatibility for existing VBx classes that already included a Finalize() procedure.  (Note that there is no such concern with Sub New() as that is invalid syntax in VBx.)

To avoid breaking existing VBx code, Wayne dropped support for the special behavior around Sub Finalize().  Any tB code that was using Finalize() should simply use Class_Terminate() instead.

Around the Web

Do we want typedef support?

Ben Clothier started an interesting discussion around the idea of typedef support in twinBASIC.  This topic is particularly relevant if you use a lot of API calls in your applications.

Kr00l suggested a variation of the UDT declare syntax to introduce a typedef in tB:

Public Type HWND As LongPtr
Public Type HMENU As LongPtr

In other words, an HWND variable would represent a subset of all long pointers, while an HMENU variable would represent a different subset of long pointers.  Specifically, a variable declared as HWND would represent a window handle, while an HMENU variable would represent a menu handle.  

Thus, it would not make sense to write the following code:

Dim MyWindow As HWND
Dim MyMenu As HMENU

MyWindow = MyMenu

That said, typedef's in C/C++ are nothing more than aliases.

In C/C++, typedefs are treated exactly as if they are of the underlying type, and so in the example you gave, the values can be interchanged without any form of casting whatsoever.

In other words, the non-sensical code above would not prevent compilation.  Ben recommended that Option Strict mode should, in fact, prevent compilation of the above code.  I strongly agree. Any time you can turn runtime errors into compile-time errors, you are creating code that's easier and less expensive to maintain.

Some Bugs are Better than Others
Not all bugs are created equal. Avoid the expensive ones by making more of the ones that are easy to find and fix.
No Longer SetMike Wolfe

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.10.5788, 10th September 2021]

[v0.10.5767, 9th September 2021]

  • fixed: (regression since v0.10.5646) class field initializors to allow for any order of class declarations in New
  • fixed: (regression since v0.10.5646) class field initializors causing compiler crash in some instances

[v0.10.5755, 9th September 2021]

[v0.10.5735, 8th September 2021]

[v0.10.5725, 8th September 2021]

  • fixed: variables should not be considered referencable inside brackets [ https://github.com/WaynePhillipsEA/twinbasic/issues/416 ]
  • added: EXPERIMENTAL [IdeButton("/miscellaneous/image.jpg")] attribute for VS Code extensibility
  • added: EXPERIMENTAL Debug.ExecuteHostCommand method for executing VS Code commands / VS Code extensibility

[v0.10.5711, 7th September 2021]

[v0.10.5646, 6th September 2021]

[v0.10.5494, 6th September 2021]

[v0.10.5474, 6th September 2021]

Never miss an article.

Sign up to receive a Sunday morning email with links and recaps of the seven articles published that week.
(I'll never sell your email. Unsubscribe any time.)


Enter your email
Subscribe

All original code samples by Mike Wolfe are licensed under CC BY 4.0