twinBASIC Update: October 31, 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

Clipboard object initial support

From Wayne:

The Clipboard object is now partially supported in v0.11.1331, providing initial implementations for Clear, GetText, SetText and GetFormat.

Also added vbCFUnicodeText to the enumeration for Unicode support.

New custom control sample – Wayne's TextBox

There's a new custom control demonstrating some of the advanced features that can be achieved with custom controls, such as:

• Text decorations (e.g., squiggles, underlines, custom back-/foreground colors)
• Rounded corners
• Gradients
• Overflow modes (e.g., shrink to fit, appended ellipsis, etc.)

Here's an animated sample:

Around the Web

Allowing Return as an alias for Exit Sub

Ben Clothier started an interesting discussion about whether to allow a bare Return call to act as an alias for Exit Sub.

Here is his rationale:

Expected behavior
No error. It should be legal to return. Had I put in something to return (e.g. Return 1 or Return "foo"), then it's appropriate to show an error since it's a Sub.

BTW, I prefer this over Exit Sub because this avoids the need to change the code should it change from Sub to Function (or vice versa).

Supporting this feature would break backward compatibility in a very narrow way.  The issue is that a bare Return statement with no matching GoSub in VBx is a runtime error and not a compile error.  So, it is theoretically possible that some madman out there is relying on a bare Return raising a runtime error and when that code gets converted to twinBASIC...and does not raise an error...then his code will stop working.  But, you know what?  Screw that guy.

Or, as Wayne much more diplomatically put it:

That just leaves the nonsensical use of Return, with it throwing a runtime error in the old syntax without any Gosub appearing in the procedure... and I feel that supporting that 'feature' would be taking the 100% compatibility goal too literally here, without considering the bigger picture.

Near-term roadmap

According to Wayne, the next two priorities in November will be:

1. 64-bit support
2. File I/O support

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.11.1355, 31st October 2021]

• improved: Unicode (UTF16) handling in WaynesTextbox CustomControl example and for the internal supporting framework handling of surrogate pairs

[v0.11.1331, 30th October 2021]

• added: WaynesTextBox control, and Example_TextBox form to Sample 6 (CustomControls)
• added: OnKeyPress event to CustomControl elements
• added: TextDecoration support for all CustomControl elements
• added: MouseEvent.TextPosition for tracking which character of an elements Text value is being hovered over
• added: global Clipboard object (predeclared class for now, later off Global class) with initial implementations of Clear, GetText, SetText and GetFormat
• added: vbCFUnicodeText to the supported clipboard formats to allow storing and retrieving unicode data from the clipboard
• removed: TextRendering.ShrinkToFit boolean, replaced with OverflowMode with options of tbAllowPartialChars, tbDisallowPartialChars, tbAppendEllipsis, tbShrinkToFit