twinBASIC Update: December 17, 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

Weekly Teaser

Another week goes by without a new release of twinBASIC.

The extended delay has not gone unnoticed to users like fafalone:

it's now been one full month since the last release. seems to be the longest gap ever. i know there's huge improvements on the way but damn this is a rough wait 😵

It would seem the delay is not due to a lack of interest from the development team, as Wayne responded, simply:

Trust me, it'll be worth the wait.

Discord Chat Summary

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

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

  • There was extensive discussion around potential funding models to support continued development of twinBASIC, with estimates around needing 100k Euros per year. Crowdfunding from the community was proposed as one option.

  • Work continues on the next major twinBASIC release, with the longest gap ever between releases now at 1 month. Hints were given that it will be worth the wait.

  • Features like PNG transparency in PictureBox, LLVM optimizations, and enums with non-Long types were discussed. The twinBASIC team is looking at implementing improvements in these areas.

  • Community members continue finding obscure bugs and edge cases, reporting them to help improve stability. The team acknowledges the next release will take time to stabilize.

  • Conversations around potentially open sourcing parts of the project continued, with suggestions like starting with the IDE source code to allow more community contributions.

  • Microsoft's own specifications around things like COM enums appear to contradict how VB6 actually implemented them. The team is weighing being strictly standards compliant vs maximizing capabilities.

Overall, progress continues towards the next major twinBASIC release that will bring many new capabilities, though it is taking longer than usual. The team remains committed to supporting the community and discussing ways to sustain project development long-term.

Around the Web

LimitInputEdit: Easy Input Filtering for TextBoxes

Another new twinBASIC project from fafalone is now available on GitHub:

This is an updated, x64 compatible version of my VB6 demo of the shell32.dll API SHLimitInputEditWithFlags, an API entirely undocumented either by Microsoft or 3rd parties until my project. There are three versions of the project in this repository, LimitInputEditWithFlags.twinproj, a full twinBASIC version that uses Return and Handles syntax etc, and a universal compatibility version (VB6, VBA6, VBA7 32bit, VBA7 64bit, twinBASIC 32bit, twinBASIC 64bit) in both VB6 and twinBASIC form with identical code.

tbShellLib Being Rebranded as WinDevLib

fafalone will be renaming his tbShellLib project to WinDevLib to better reflect the expanded scope of the project:

I'm planning on renaming this project to WinDevLib - Windows Development Library for twinBASIC, to better reflect the purpose, since as it's grown the original mission of shell programming has become only a part of it; the largest single part, but not even close to a majority anymore. Also a couple other significant changes, including redefining LARGE_INTEGER to QuadPart As LongLong instead of high/low Longs... this in accordance with how it's treated by the Windows API--- the C definition is a Union between both options, but this means it always triggers 8-byte alignment rules. Problems from not having that were rare in 32bit, but so common in 64bit it was previously relegated to legacy compatibility and all internal defs used QLARGE_INTEGER instead. But that's not a real Windows type.

I was hoping to hold off on this change until tB had union support, so the 8 byte alignment issue could be resolved without breaking compatibility with low/high Long usage. But with that pretty much ruled out as a 1.0 feature recently, I feel it's important to go ahead and make this change (and the name change) now before tB hits 1.0, since once tB is a stable product I think the same applies to major community projects around in beta.

So LARGE_INTEGER will now have .QuadPart only, and all QLARGE_INTEGER will be replaced with LARGE_INTEGER. Less impactful but still of note, SendMessage and PostMessage will now follow the same API standards as the rest of the project, pointing to SendMessageW and PostMessageW respectively, and using DeclareWide. This won't impact >99% of usage, since using a String with DeclareWide is the same plain usage without conversion it's always been, but it's still worth noting. Both this and the other change are noted in [ Description ] attributes.

The existing versioning will be retained; the initial release will be 7.0.272. Compiler constants will be updated; e.g. WINDEVLIB_LITE instead of TB_SHELLLIB_LITE.

Let me know if there's any thoughts, comments, suggestions, questions, objections, or as always, coverage requests; it will still be a couple days before the new version is initially released.

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.

No new releases this week.