twinBASIC Weekly Update

twinBASIC Update: June 26, 2022

Highlights include container support, IDE bug fixes, and a modest request for a complete backward-compatible rewrite of MS Access in twinBASIC.

Mike Wolfe

Jun 26, 2022 • 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)

Highlights

Container Support

BETA 61 added "highly experimental container support (frames, etc.)" and also "added Container property to all controls."

IDE Bug Fixes and Minor Improvements

While light on brand new functionality, this week was heavy on bug fixes and incremental improvements to the IDE, including:

Improved sorting and performance of arrays in the Local Variables window
Prevention of infinite loop at IDE startup under certain error conditions
Fixed bug related to mouse click problems in design view of tab controls

Around the Web

Improved Support for SSTABX

It took a lot of back and forth for Wayne to be able to reproduce the problem, but after a long and winding journey, the SSTab control seems to be behaving itself in design view on high-DPI monitors.

What is the SSTabEx control?

Honestly, I'm not sure. It seems to be more of a VB6 thing than an Access/VBA thing. In any case, there was some strange behavior where clicking on one tab in design view would switch to a different tab than the one that was clicked.

As an outside observer, it looked like a big part of the issue was that the design environment of the twinBASIC IDE is HTML/JavaScript-based (since it's running Monaco inside a Webview2 control), while at runtime the control was running natively in twinBASIC.

While the exact details of this incident may not mean much to your specific use case, I think it's a good glimpse inside the effort that Wayne is putting forth to achieve 100% (not 99%) backwards compatibility with VBA/VB6.

twinAccess

While the VB6 community is excited about the potential to finally be able to create 64-bit versions of their VB6 projects with twinBASIC, that's not as big a deal for Access developers who've had 64-bit support since the release of VBA7 along with Office 2010.

The Holy Grail for Access developers would be a way to convert existing Access applications into standalone twinBASIC executables with no runtime dependency.

Mark Burns recently proposed the idea (and name) in a comment on this blog:

I have one thought - a total non-MS functional re-write of MS-Access from the ground up - written entirely in twinBasic:
[...]
...call it TwinAccess?

And over on Github, user Heartlander echoed that sentiment:

Wayne, I know you are up to your eyebrows in tB but has anyone sketched out what all you would have to do to convert an Access app to a compiled TwinBasic program? Thanks.

So, what do you say, Wayne? Maybe throw this one on the roadmap for Q2 2023? Can't be that hard, amirite? 😁

Changelog

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

BETA 62

improved: better support for SSTabEx [ needs very latest release of SSTabEx ]
improved: removed project path from tB title bar (now just filename, with path available via hover tooltip) [ EduardoVB, discord ]

BETA 61

added: highly experimental container support (frames etc). Tab-key navigation/focus not yet working here.
improved: added Container property to all controls
fixed: support for ActiveX-based option buttons (e.g. VBCCR.OptionButtonW)

BETA 60

fixed: form-designer tab-click issue [ https://github.com//issues/919 ]
improved: error message and shutdown when missing compiler DLL is detected [ https://github.com//issues/929 ]
improved: form designer auto-reload restricted to 5 attempts [ https://github.com//issues/929#issuecomment-1162609703 ]
improved: performance of stack frame variables dump [ https://github.com//issues/928 ]
fixed: sorting of arrays in stack frame variables dump [ https://github.com//issues/928 ]

BETA 59

fixed: muted the unintentional 'ProcessPendingMessages' debug messages in the debug console when using the form designer
fixed: form designer control mouse clicks feature was not working when Zoom was set to anything other than 100% [ https://github.com//issues/919#issuecomment-1160560343 ]
fixed: tweaked the IDE form designer snapshots to work better on Windows 7 machines
improved: saving the Settings file now restarts the compiler process without prompting
fixed: CodeJock property page not allowing to Insert tabs [ https://github.com//issues/927 ]
improved: some support for Windows Media Player control (audio now working, video not)
fixed: support for MSComCtl2.FlatScrollbar
improved: implemented all known Ambient properties to try to improve overall Ax support
fixed: missing toolbox icons for Ax controls that used the REG_EXPAND_SZ type for the ToolboxBitmap32 entry in the registry (e.g. WMP)

BETA 58

fixed: rogue 'expression is neither used nor assigned' error in some cases involving dispinterfaces [ https://github.com//issues/925 ]
fixed: some property sheet hidden window issues [ https://github.com//discussions/924#discussioncomment-2979817 ]
fixed: non visual controls added to a form were not displaying their icons for their psuedo content [ https://github.com//discussions/924#discussioncomment-2981643 ]
fixed: pressing delete key when only the form element was selected would invalidate the form
improved: there was no visual clue when a non-visual control was selected within the form-designer
improved: double-clicking on a control in the toolbox adds an instance of the control to the center of the form [ Krool, discord ]
fixed: re-enabled designer control click support, disabled in last release to investigate some issues [ https://github.com//discussions/919 ]
improved: added 'Launch EXE' and 'Open Folder' links in the debug console following a successful build
fixed: potential premature Activate event before all controls are fully created [ https://github.com//issues/920 ]