twinBASIC Update: January 8, 2023

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

VBP UserControl Import

As of BETA 224, VBP forms containing UserControls (non ActiveX) now import correctly.

VBCCR Control Support

All controls (except for CoolBar) from Kr00l's Visual Basic Common Controls Replacement library project are now working as UserControls in twinBASIC.  

There is a known memory leak issue that should be addressed in the coming days.  As a result, you will want to ensure Large Address Aware is turned on in the twinBASIC IDE settings or you will quickly run out of memory and the IDE will crash.

Below are the relevant messages on this topic from the twinBASIC Discord server (all times Eastern Standard Time).

Wayne Phillips on 2023-01-02 at 03:38:

With BETA 219, most VBCCR controls now work as UserControls (at least to some extent), provided you disable SetVTableHandling and GetTopUserControl functions (edit both procedures to just Exit Function as the first statement).

Wayne Phillips on 2023-01-05 at 03:02:

With BETA 221, it is no longer necessary to disable the vtable patching to support VBCCR UserControls.  Though it is still necessary to disable GetTopUserControl function for now.

Wayne Phillips on 2023-01-06 at 11:42:

With BETA 222, all VBCCR (UserControl) controls can now be added to forms, except for CoolBar.  None of them have been extensively tested; just up to the point of showing up in the form designer, and previewing a form containing them.

The main issue with using the VBCCR UserControls now is the significant memory leak(s).  For example, In the VBCCR demo project, in a blank form, just adding a control or making a property change causes a 200MB+ memory leak.  That's the next priority to get sorted.

It is no longer necessary to make any changes to the VBCCR source code (i.e. don't modify SetVTableHandling/GetTopUserControl anymore)

Due to the memory leaks, if you want to try out VBCCR UserControls, it is currently advisable to turn on LargeAddressAware (LAA) in the IDE settings (not the project settings), otherwise you'll only be able to add a few controls to a form before the compiler exhausts the available address space and crashes.

Wayne Phillips on 2023-01-08 at 03:03:

As of BETA 224, VBCCR ComCtlsDemo MainForm form now imports correctly, apart from the CoolBar control that isn't working in tB yet.

VBCCR COM Controls Demo Project

Wayne also posted a demo twinBASIC project with the VBCCR controls on Discord.  I've put a copy of the .twinproj file on my web server so that it's available without needing to create a Discord account:

Here's the twinproj which is an unmodified import of the VBP from Krools GitHub repo (https://github.com/Kr00l/VBCCR), with the OLEGuids.tlb typeibrary imported: VBCCR_ComCtlsDemo.twinproj

(note that the MainForm doesn't actually run live yet, but we're very close now that virtually all of the controls are rendering properly)

Experimental Hover Tips

BETA 221 introduced an experimental feature for debugging live variables and expressions while code is executing.  Unlike VBA, the hover tip will resize to display the entire variable value (in VBA, hover shows only a portion of long values, though a [Ctrl] hover will show the partial value from the other side).

The twinBASIC version also shows member properties of object variables.  Here's a quick demo from Wayne:

Around the Web

Breaking Changes - Post twinBASIC v1

Andrew Mansell raises an interesting dilemma over on GitHub:

In a greenfield project, once a project reaches v1 it's best to try and avoid breaking changes, almost at any cost. However, twinBASIC is not strictly greenfield, given that it has an absolute design goal to be 100% backwards-compatible with source code written for legacy VB6 SP6/ VBA6 / VBA7 (aka VBx).

VBx is not fully specified. There are API docs, but VBx has lots of undocumented implementation details (quirks) that have to be accommodated if source code is to be fully portable from VBx to twinBASIC. The current level of compatibility is impressive, but edge-cases continue to be unearthed. Given the opaque nature of VBx, this is likely to be the case for some time.

This raises an interesting dilemma. Once twinBASIC v1 has been released, what should be done when back-compat issues are discovered? Especially when a fix could create breaking changes between twinBASIC versions?

One popular versioning protocol is Semantic Versioning.  I can't remember whether Wayne has offered his opinion on semantic versioning and whether twinBASIC will adhere to it (and how strictly).  If you've never heard of it, here are the basics:

Given a version number MAJOR.MINOR.PATCH, increment the:
1. MAJOR version when you make incompatible API changes
2. MINOR version when you add functionality in a backwards compatible manner
3. PATCH version when you make backwards compatible bug fixes

There's an exception to the above for pre-release development when breaking changes occur frequently:

Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.

If Wayne does decide to use semantic versioning, it is quite clear on how breaking changes should be handled:

Major version X (X.y.z | X > 0) MUST be incremented if any backwards incompatible changes are introduced to the public API.

If Wayne plans on following semantic versioning, I suggested the following approach:

I'm not sure how much extra work it would be for Wayne, but maybe any post-tB1 VBx incompatibilities that are also tB1 breaking changes should immediately go into a tB2-alpha. Basically, a fork of tB1 with VBx bug fixes that break compatibility with tB2.  If the goal is to follow semantic versioning, that seems one way to do it without blowing through a bunch of major twinBASIC version numbers.

I should also note that semantic versioning explicitly supports pre-release/alpha versions of post-v1 versions:

A pre-release version MAY be denoted by appending a hyphen and a series of dot separated identifiers immediately following the patch version. ... A pre-release version indicates that the version is unstable and might not satisfy the intended compatibility requirements as denoted by its associated normal version.

This approach would comply with semantic versioning, while still making the most VBx-compatible version of twinBASIC always available to those VB6 developers that may need it.

This is an important issue to hash out in advance of the upcoming v1 release.  If you have thoughts, I would encourage you to share them on GitHub.

Changelog

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

Releases · WaynePhillipsEA/twinbasic
Contribute to WaynePhillipsEA/twinbasic development by creating an account on GitHub.
GitHubWaynePhillipsEA

WARNING: The following two issues are present in BETA builds 202 - 224 (the latest build as of publication):

  • building ActiveX controls is known to be broken in these builds.  Use BETA 201 instead for that feature.
  • there are known memory leaks in these versions, so memory usage will be higher than normal

BETA 219

  • fixed: UserControl Anchors not working [ sokinkeso, discord ]
  • added: support for UserControl ScaleX/ScaleY vbContainerSize and vbContainerPosition options

BETA 220

  • improved: form designer property sheet sorting is now case-insensitive [ fafalone, discord ]
  • fixed: (regression) Memory Locked error possible with some For-Each statements, since BETA 211 [ https://github.com//issues/1443 ]
  • fixed: tB implementation of DoEvents freezes when called from VBA [ https://github.com//issues/1440 ]
  • fixed: DirListBox / FileListBox default path should be App.Path [ fafalone, discord ]
  • fixed: default font size for DriveListBox / DirListBox / FileListBox was too large [ fafalone, discord ]

BETA 221

  • fixed: constants referencing an enumeration value would sometimes fail to resolve [ https://github.com//issues/1441]
  • fixed: IUnknown/IDispatch implementations no longer rely on private hidden vtable members [ VBCCR ]
  • added: (experimental) hover information for debugging live variables and expressions within the code editor

BETA 222

  • fixed: Form and UserControl vtable edge cases to match VBx [ VBCCR.GetTopUserControl ]
  • fixed: potential IDE hang during project editing due to race condition in global variables cleanup
  • fixed: resolved some conflicts that were preventing use of certain symbols as property names in UserControls [ fafalone, tbShellBrowse.ControlType ]
  • improved: support for VBCCR control as UserControls [ all controls except CoolBar can now be added to forms ]

BETA 223

  • fixed: removed output of internal debug info during form editing
  • fixed: Bang vs datatype suffix parser error [ https://github.com//issues/1450 ]
  • fixed: (regression) newly inserted event procedure signatures could sometimes include interface '_' prefix on datatypes [ Krool, discord ]
  • fixed: OptionButton would fire two click events in some instances [ sokinkeso, discord ]
  • fixed: Control array group objects were not working late-bound (though Object) [ sokinkeso, discord ]

BETA 224

  • improved: VBP forms containing UserControls (non ActiveX) now import correctly