twinBASIC Weekly Update

twinBASIC Update: October 22, 2024

Highlights include a new tB-based Magnifier Windows utility from fafalone, a project status update from Wayne, and a metaphor involving rubber ducks, hippos, and oxpeckers.

Mike Wolfe

Oct 22, 2024 • 6 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~~ ~~Monday~~ week, 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, please leave a comment below.

Here are some links to get involved with the project:

Highlights

Nose to the Grindstone: twinBASIC Forms Edition

Note from Wayne Phillips in Discord (posted 15 Oct 2024):

I've had a few messages today, with concerns over how quiet it is at the moment. Don't worry... all is going fine! I'm just very deep in the forms engine, trying to perfectly match behaviours to VB6 at a very detailed level. It's very intricate work, but is necessary, and I'm confident we'll see improvements to compatibility once complete. Please hold on there for a couple of weeks... it'll be worth it!

Discord Chat Summary

^{* Auto-generated via Claude-3.5-Sonnet-200k on poe.com}

Here's a summary of the key points from the twinBASIC Discord chat transcript for the General channel from October 15-21, 2024:

The past week saw continued development and discussions around twinBASIC, with a focus on compatibility, forms engine improvements, and community engagement. Here are the main highlights:

• Wayne Phillips, the lead developer, provided an update on the current development focus, stating he is "very deep in the forms engine, trying to perfectly match behaviours to VB6 at a very detailed level." This work aims to improve compatibility with legacy VB6 code.

• There was discussion about the complexity of creating a VB6-compatible compiler, with community members acknowledging the significant challenges involved, especially regarding undocumented behaviors.

• The twinBASIC team announced strong support for their perpetual license offer, including backing from larger businesses, which is crucial for the project's long-term success.

• Developers explored various API and COM interop scenarios, including working with ActiveX EXEs, clipboard operations, and interface implementations.

• There were conversations about potential future features, such as support for "free" functions (similar to VB.NET's shared functions) and improvements to testing workflows within the IDE.

• The UK Access User Group Autumn 2024 Conference was promoted, featuring sessions on twinBASIC among other topics relevant to Access and VBA developers.

• Community members discussed and compared different aspects of twinBASIC with other languages and frameworks, highlighting its unique position in modernizing legacy VBA code.

In conclusion, this week's discussions demonstrate twinBASIC's ongoing evolution, with a strong focus on VB6 compatibility and forms engine improvements. The positive response to licensing options and business support indicates growing adoption and a promising future for the project. Developers continue to explore twinBASIC's capabilities and potential features, showcasing its relevance in modernizing legacy code while maintaining compatibility.

Around the Web

Magnifier Demo

Here's the latest project from fafalone as announced in show-and-tell:

This is a quick port of the Windows SDK example for the Magnification API.

There's two versions:
- The original twinBASIC version, made using WinDevLib, so all APIs/UDTs/etc were already defined.
- A backported VB6 version, which uses local copies of the defs. It's still 64bit compatible and can readily be imported to tB and compiled for either 32 or 64 bit.

At the top of the code you'll find options for the zoom factor (default 2.0) and whether to invert colors (default false).

Potential Symbiosis: tBA and Rubberduck-VBA

During my presentation to the UK Access User Group next month (tickets available here), I will be demoing the (still-highly-experimental) twinBASIC for Applications (tBA). This is the feature that allows you to edit VBA code using the twinBASIC IDE–and all the benefits that come with that, including:

Code folding
Sticky-scrolling
Code block closing hints
More capable syntax highlighting

If you've been following the twinBASIC project for a while, you may know that Wayne initially avoided trying to integrate twinBASIC directly into the VBA development environment. I presume the following three considerations heavily influenced that decision:

It's a monumental technical challenge
It's potentially risky from the legal perspective (best to "let sleeping Microsoft patent attorneys lie", as the saying doesn't quite go)
The upcoming release of Rubberduck 3 promised to offer its own alternative to the VBA IDE

Wayne Phillips is the Jon Skeet of the VBx world, so he surmounted #1 with ease.

Microsoft is not exactly enamored with VBA these days, so #2 is much less risky than it once was. (Easy for me to say; I've got no real skin in the game.)

Which brings us to #3: the Rubberduck VBA project. Here's the 30,000-foot view of the upcoming Rubberduck 3 project from its GitHub readme (emphasis mine):

Long story short, Rubberduck is undergoing an almost-complete rewrite. Key points:

We're implementing a language server (LSP) for VBA

We're making our own standalone editor / LSP client

We're writing all of it with the latest version of C# and .net

No, we're not going to be compiling VBA executables (this unfortunately means no debugger and designer features)... not now anyway.

Yes, we're still integrating with the VBE - but we're breaking free from it nonetheless

The original readme announcing plans to develop a VBA editor replacement was posted more than two years ago. While the project has made steady progress, the technical challenge is no less daunting than it is for tBA. Mat Guindon and crew are all capable programmers...but they're also donating their time on the project.

So where does that leave Rubberduck and tBA?

Well, here's how the original Rubberduck 3 Readme concluded:

...by implementing our own editor we get to finally be in charge and ignore every single limitation of the VBE; we get to just make Rubberduck into the tool we always wanted it to be.

In other words, the proposed "Rubberduck VBA Editor" was merely a means to an end.

The project had pushed the built-in VBA IDE as far as it could go. To take on the sort of advanced refactoring and static code analysis it dreamed of, it needed to break free from those limitations. At the time, the only conceivable way to do that was with their own editor.

The potential release of tBA changes that calculation.

Why create another Visual Studio when what you really want to create is Resharper for VBA?

In this metaphor, tBA is Visual Studio and Rubberduck 3 is Resharper for VBA.

The truly important question regarding this envisioned symbiotic relationship is this: which project is the hippo...and which one is the oxpecker?

Reddit: VB6 alternatives today?

Question recently posted on Reddit:

Back in the 90s I used code a lot in VB5 and then VB6. It was great. Drag and drop elements on a form. Do some coding. Nothing fancy. ...

Now I want to get back into this kind of development. Is there any similar solutions these days?

The top two highest-voted answers on the page both prominently mention twinBASIC as an obvious solution.

Changelog

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

No new releases this week.