twinBASIC Update: September 24, 2023

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

twinBASIC Services Status at a Glance

As of BETA 397, there is a single green/orange/red status bar in the bottom left of the twinBASIC IDE window to indicate the state of the following tB services:

Compiler
FS
LSP
Debugger

As far as I can tell, there is no documentation about the purpose of this new status bar or what each of the systems represents.

I consulted with ChatGPT to make some educated guesses to fill in these blanks. I provided it specific context about the twinBASIC project. It used its vast knowledge of programming languages and development environments, generally, to provide broader context.

Here's the result of our collaboration:

Compiler: This status reflects the operational state of the Compiler subsystem in twinBASIC. The Compiler is responsible for translating the source code into machine code. An "Operational" status indicates that this subsystem is functioning as expected and is capable of performing its duties without any known issues.
FS (File System): The File System status represents the operational state of twinBASIC's internal file system. This subsystem is responsible for handling the .twinproj files, which are binary containers that include all individual source files of a project. An "Operational" status signifies that this subsystem is functioning correctly, managing .twinproj files without any known issues. In the future, with the addition of support for external files, the role of the .twinproj file may evolve to act more like a "solution" file as seen in other programming languages. This change will expand the responsibilities of the File System subsystem, managing both internal and external files while maintaining the integrity of the project structure.
LSP (Language Server Protocol): This status reflects the operational state of the Language Server Protocol subsystem. The LSP subsystem provides intelligent programming features like auto complete, go to definition, find all references, etc. An "Operational" status means that this subsystem is functioning as expected and is ready to provide these features with no known issues.
Debugger: This status indicates the operational state of the Debugger subsystem. The Debugger subsystem is used to test and debug programs, allowing the programmer to step through the code line by line, inspect variables, and follow the flow of execution. An "Operational" status signifies that this subsystem is functioning as expected, capable of debugging tasks without any known issues.

In the context of a BETA phase software like twinBASIC, these "Operational" statuses are likely included to provide instantaneous feedback about the health of each subsystem. This can be beneficial for both the developers and users in understanding the overall system health and in diagnosing potential issues.

I want to emphasize that the above summary involves a lot of tea-leaf reading on my part. It's possible that I am simply way off course with my explanations.

However, I did do some quick testing of the status bar which is what led me to believe that its purpose is to provide information about the twinBASIC IDE itself and not the application under development.

Specifically, I tested to see whether the statuses changed from "Operational" to ... literally anything else as I performed the following actions:

Entered debug mode
Paused code execution at a breakpoint
Intentionally created syntax errors

The screenshot below shows the Problems window populated with a syntax error but the tB Services status bar continuing to show a green OPERATIONAL status for all systems:

Discord Chat Summary

^{* Auto-generated via Claude-2-100k on poe.com}

Here is a summary of the key points from the general channel Discord transcript for twinBASIC over the past week:

Recent Releases and Updates

Beta 397 was released, which fixed some IDE issues like automation errors popping up
There were some bugs found with array initialization and high memory usage that will be addressed in upcoming releases

Language Features

Discussed how Dim(1 to Count) arrays are allocated currently - they seem to be stack allocated but there were some issues using debug code
Const expressions allow things like compile-time input boxes and complex constant calculations, a nice addition over VB6
Overloading APIs is supported, allowing multiple versions of APIs to be defined

IDE/Editor

Some strange issues reported with IDE disappearing or rendering incorrectly on multi-monitor and high DPI setups on Windows 11
Problems noted with maximize/restore buttons not working properly, makes IDE difficult to reposition

Compatibility and Porting

VBG multi-project support likely won't make v1.0, but ideas discussed like opening individual projects from a VBG
An Access VBA project was imported but had issues parsing, found to be file location related

Community and Support

User testing help requested for strange control rendering issues in Office VBA IDEs on some systems
Memory issues diagnosed for large AoC2015 project that works in VBA but not twinBASIC due to 32-bit memory limits

Overall good progress this week in bug fixes and testing as twinBASIC marches toward the v1.0 release. Compatibility and stability continue improving while new language features are added. The community is steadily growing and assisting with testing, porting, and debugging.

Here is a summary of the key points from the addins channel Discord transcript for twinBASIC over the past week:

Keyboard shortcuts can now be registered for add-ins using the Host.KeyboardShortcuts API. This allows assigning keyboard shortcuts to add-in functions.
Sample code was provided for creating a basic two-column layout in an add-in using a ListView and div tags. CSS can be used to set column widths.
The FileUIDESIGNER file type hook encompasses .tbform, .tbcontrol, and property pages. A suggestion was made that these could be separate hooks in the future to allow handling them differently.
The new keyboard shortcuts feature was noted as a good starting point for an IDE macro recorder/editor.

Overall, progress continues on expanding the add-in APIs and capabilities in twinBASIC. Keyboard shortcuts, UI layout, and CSS support were added recently. The community continues providing feedback and suggestions for future improvements.

Around the Web

VBA -> twinBASIC Geometrize Project

Over on the show-and-tell twinBASIC Discord channel, KayJayDubya posted a fascinating project he ported from VBA to twinBASIC, based on the open-source Geometrize project:

This is a simple renderer of primitives in GDI+ (in this case, lines) that were generated into JSON by the Geometrize software.

I originally wrote this demo for the VBA PictureBox drop-in class I'm (slowly, ever so slowly) writing, and I thought I'd see how easily it works in TwinBasic as-is. No changes necessary (save for the fact I didn't have to use the GetDC API to find the DC).

There is a slight pause built into the code between each bunch of lines being drawn to the hDC to demonstrate the 'drawing' effect

clsPresenceMon

This week's sample twinBASIC project from fafalone monitors various Windows events that can be used as a proxy for whether a user is present at the computer, such as monitor state (on/dim/off) and laptop lid position (open/close).

Here's the intro from the project Readme on Github:

A self-contained, threaded class to monitor user presence in several ways

This is a simple class that monitors for 3 events: The monitor state (off, on, or dimmed), the system's 'user present' message, and, if you're on a laptop, the lid status (open, close). It does this in an entirely self contained class-- the complication with this arises because these events are sent in the form of a WM_POWERBROADCAST message, requring a window to receive it. But I didn't want to limit the class to graphical apps and just subclass a form hWnd, although for the sake of completeness the demo app shows how to do it that way too. So the class creates it's own entirely custom hidden window, in a separate thread to avoid the message loop blocking the Form's message loop if present.

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

ChatGPT Changelog Summary

^{* Auto-generated via ChatGPT, sorted in order of ChatGPT's opinion of "most impactful changes.}"

Here's a summary of the most notable updates in twinBASIC:

Improved: Compiler services status notifications in the IDE have been simplified into a single red/orange/green state in the status bar, providing a clearer, more intuitive user experience.
Fixed: A range of issues with ListView, such as the ListItem.Selected property-let not correctly updating the LVIS_FOCUSED flag and potential hard crashes when adding items/columns and unloading the form. This stabilizes the behavior of this commonly used control.
Fixed: Several issues with user controls, including the UserControl.PropertyChanged signature not perfectly matching VB6 and problems with control arrays in a user control causing dispatch table problems. These fixes ensure better compatibility with VB6.
Fixed: Implicit WithEvents fields created for Form/UserControl contained controls are now not bindable directly, aligning with VBx behavior. This resolves potential confusion and inadvertent errors.
Added: Initial support for importing PropertyPages from VBPs, although full support is not yet available. This marks the first step towards better compatibility with VB6's property pages.
Fixed: An edge case causing modal windows owned by another process to close when the owner window is minimized. This fix ensures more reliable window behavior in multi-process scenarios.
Fixed: Several miscellaneous bugs, including issues with intellisense, declare statements, and form window state restoration, improving the overall stability and usability of the language.

Please note that minor bug fixes and specific edge case issues have been omitted in this summary for brevity.

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

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

BETA 394

fixed: ListView ListItem.Selected property-let was not correctly updating the LVIS_FOCUSED flag [ sokinkeso, discord ]
fixed: SW_SHOWWINDOW edge case causing modal windows owned by another process to close when the owner window is minimized [ sokinkeso, discord ]
fixed: some internal issues when using Collection in an Implements-Via statement
fixed: adding ListView items/columns and TreeView nodes could potentially cause a hard crash when the form is unloaded [ sokinkeso, discord ]

BETA 395

fixed: missing codegen for set-assignment of UDT field that is a Variant dynamic array element [ FullValueRider, discord ]
fixed: (regression since BETA 393) using Len()/LenB() in fixed length array bounds expressions was being detected as an error
fixed: implicit Variant warning not triggered on ByVal parameters inside Declare statements [ https://github.com//issues/1680 ]
fixed: intellisense not populating for ReDim myUDT. [ https://github.com//issues/1682 ]
fixed: UserControl.PropertyChanged signature did not perfectly match VB6 [ https://github.com//issues/1681 ]
fixed: having control arrays in a user control caused dispatch table problems [ nextKast, discord ]

BETA 396

fixed: implicit WithEvents fields created for Form/UC contained controls are now not bindable directly, only through the Form/UC implicit property-getter as per VBx
fixed: (IDE) form property sheet was unintentionally showing an internal property 'InternalIsFirstResizeEventAfterLoad'
added: initial support for importing PropertyPages from VBPs
NOTE: PropertyPages are not yet fully supported, just imported!

BETA 397

fixed: (IDE) 'Run-time Error 5: Automation Error' pops up from the IDE when the system is awoken from suspended state
fixed: Form.WindowState = vbNormal failing to restore the window when already maximized (also affecting IDE) [ https://github.com//issues/1634 ]
fixed: (IDE) monitoring of active running shelled processes are now cleared when the compiler gets restarted [ fafalone, discord ]
improved: (IDE) compiler services status notifications are now simplified into a single red/orange/green state in the bottom left status bar