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:
- Custom twinBASIC IDE Installation Guide
- GitHub Issue Tracker (report bugs)
- twinBASIC Discord Server (chat about the project)
- twinBASIC/VBx LinkedIn Group
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 APISHLimitInputEditWithFlags
, 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 usesReturn
andHandles
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 redefiningLARGE_INTEGER
toQuadPart 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 usedQLARGE_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.
SoLARGE_INTEGER
will now have.QuadPart
only, and allQLARGE_INTEGER
will be replaced withLARGE_INTEGER
. Less impactful but still of note,SendMessage
andPostMessage
will now follow the same API standards as the rest of the project, pointing toSendMessageW
andPostMessageW
respectively, and usingDeclareWide
. This won't impact >99% of usage, since using a String withDeclareWide
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 ofTB_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.
No new releases this week.