twinBASIC Weekly Update

twinBASIC Update: April 10, 2023

Highlights include the addition of SendKeys support, CDecl support for certain types of API callbacks, and a vigorous discussion about possible tB namespace support.

Mike Wolfe

Apr 10, 2023 • 4 min read

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:

Custom twinBASIC IDE Installation Guide (NOTE: the twinBASIC VSCode extension is under a feature freeze until 2023)
GitHub Issue Tracker (report bugs)
twinBASIC Discord Server (chat about the project)
twinBASIC/VBx LinkedIn Group

Highlights

SendKeys Support Added

While it will need to be updated for cross-platform support, the SendKeys method has been implemented according to Kr00l's suggestion:

[F]or the time being, include a quick solution for the VBA lib:

Public Sub SendKeys(ByRef Text As String, Optional ByRef Wait As Boolean)
    CreateObject("WScript.Shell").SendKeys Text, Wait
End Sub

Until you have the resources to provide an independent cross-platform solution...

Experimental CDecl Support for API Callbacks

From Wayne:

As of BETA 287, the CDecl calling convention is now supported for all internal procedures, so for example, you can now define a CDecl callback:

Function MyCDeclCallback CDecl(ByVal A As Long)
End Function

And thus using AddressOf MyCDeclCallback now gives you a function pointer that is CDecl compatible.

(note: syntax copied to match the existing CDecl support in declare statements, where the CDecl keyword is expected immediately following the procedure name)

Wayne provided some additional explanation about the importance of this support in Discord:

Calling conventions describe to the compiler how a function call has to be made at the architecture level, with regards to argument passing (stack vs registers), stack cleanup, register volatility etc.

Every function call has a particular calling convention. In C/C++ this defaults to cdecl, but on Windows x86 it much more typically defaults to stdcall. The differences are very important; if the compiler uses the wrong calling convention, it will lead to significant problems (i.e. runtime crashes).

Since the default for us is typically the stdcall calling convention, we largely don't need to be concerned about it. The times that we do need to be concerned about it are when we are interacting with libraries that don't use stdcall as their calling conventions. In those cases, we might need to declare API calls with the CDecl attribute, and when passing function pointers AddressOf <proc> we might need to specify the procedure with the CDecl attribute also, if the library is expecting a cdecl-callback function pointer. This is all now possible directly in tB.

IDE Clipboard Tab to Space Conversion

Added in BETA 287:

[O]verride of monaco Copy/Cut clipboard actions with enhancement that converts tab indentations to spaces.

Around the Web

Namespace Discussion

Greedquest resurrected an earlier discussion about namespaces:

We need to move this forward, as starting from twinBASIC v1, I believe the consensus is that internal backwards compatibility - that is, backwards compatibility not just with VBA/VB6 but also with previous versions of twinBASIC - MUST be maintained. That means no more breaking changes and this will probably be one. So it needs to be resolved while still in Beta. Even if that's not the case, we should make a decision sooner rather than later, as I think namespaces will impact almost all tB code, and the longer we wait the more disruptive any change will be, both to the ecosystem of tB code and the compiler/IDE.

Changelog

Here are the updates from the past week. You can also find this information by visiting the GitHub twinBASIC Releases page.

WARNING: The following issue is present in BETA builds 202 - 286 (the latest build as of publication):

there are known memory leaks in these versions, so memory usage will be higher than normal

BETA 287

added: experimental support for CDecl calling convention for all internal procedures (e.g. syntax Function DoSomething CDecl(A, B, C)) [ https://github.com/twinbasic/lang-design/issues/25 ]

BETA 288

fixed: Implements-Via feature was not working correctly for ByRef-Aliased types (like ByRef OLE_COLOR) [ Tecman, discord ]
fixed: 'duplicate definition in the current scope' bogus errors that could appear for ActiveX controls
fixed: calling Unload within the Form.Unload event would cause a stack overflow [ Tecman, discord ]
improved: override of monaco Copy/Cut clipboard actions with enhancement that converts tab indentations to spaces [ fafalone, discord ]

BETA 289

fixed: default font for imported VBP forms is now MS Sans Serif [ Tecman, discord ]
fixed: form designer property sheet would sometimes miss some Property-Set based properties [ Tecman, discord ]

BETA 290

fixed: For-Each on a Form/UserControl directly (rather than e.g. Form.Controls) threw an error [ https://github.com//issues/1532 ]
fixed: setting App.Title before any form had been shown, would cause a crash [ https://github.com//issues/1529 ]

BETA 291

added: SendKeys now implemented (via WScript.Shell for now) [ https://github.com//issues/1274#issuecomment-1336407139 ]

BETA 292

fixed: UserControl implementation of IOleObject.GetExtent returned the client area rather than the full window extent, leading to problems using some tB compiled Ax controls in some hosts [ Tecman, discord ]