twinBASIC Update: June 17, 2024

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, 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:

• Custom twinBASIC IDE Installation Guide
• twinBASIC Discord Server (chat about the project)
• twinBASIC Wiki (list of new features not in VBx)
• GitHub Issue Tracker (report bugs)
• twinBASIC/VBx LinkedIn Group

Highlights

twinBASIC for Applications!!!!

When I missed publishing last week's twinBASIC update, Wayne must have thought he needed to do something to get my attention.

Well, MISSION ACCOMPLISHED, sir!

Introducing "twinBASIC for applications" – the game-changing drop-in replacement for VBA (and VBA SDK). See our proof of concept inside MS ACCESS in action! 🚀👨‍💻👩‍💻 #twinBASIC #VBA #Office pic.twitter.com/s1GNryJoMn

— twinBASIC / EverythingAccess (@WaynePhillipsEA) June 14, 2024

That right there is huge news.

Wayne elaborated on the video and provided some valuable context over on Reddit.  Be sure to check out the link for his full comments, but here's the (AI-generated) short version:

Wayne Phillips, the creator of twinBASIC, provided insights into the "twinBASIC for Applications" proof-of-concept video. Here are the key points:

• Client Need: The proof-of-concept was commissioned by a client whose app uses the VBA SDK for end-user customization. Due to Microsoft's neglect of VBA, they sought an alternative that supports existing VBA code.
• Host Independence: The proof-of-concept demonstrates that twinBASIC can work in any host environment, not just Office apps.
• Integration Levels:
  • Level 1: A modern IDE replacement for VBA, maintaining full VBA compatibility. End-users can use projects in the standard VBA environment without twinBASIC.
  • Level 2: Adds some extended language features with a transpiler to ensure VBA compatibility. End-users still use projects in the standard VBA environment.
  • Level 3: Full twinBASIC IDE and environment with all features and performance benefits. Requires twinBASIC installation on end-user machines.
• Legal and Product Decisions: Many decisions about the product and its availability are pending, and legal considerations may impact these decisions.
• Client Fit: For the client looking to move away from VBA, Level 3 is the best fit due to their control over software distribution. For general VBA replacement, Level 2 is optimal, starting with Level 1.

This explanation highlights the flexibility and potential of twinBASIC as a modern alternative to VBA, addressing both developer and end-user needs.

While "twinBASIC for Applications" is the obvious name for a drop-in VBA replacement, it might be a bit too close for comfort for the corporate attorneys at Microsoft.  I humbly suggest taking a page out of the Simpsons' playbook:

[Groundskeeper Willie]: Boy, you read my thoughts.  You've got the shinnin'!
[Bart Simpson]: You mean the shining?
[Groundskeeper Willie]: Shhh!! You wanna get sued?!?!

Anyway, the key is to just make a single minor adjustment to the name so that it sounds similar but it's not exactly the same.  I've even got a suggestion:

twinBASIC for Abdications

Get it?  You know, since Microsoft has basically abdicated its duty to preserve VBA as a viable programming language.  

Also, for what it's worth, I am not a lawyer, so this might not be the best legal advice.  Your mileage (kilometerage?) may vary.

Discord Chat Summary

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

twinBASIC Development Update - Week of June 6, 2024

This week in the twinBASIC general channel, discussions revolved around performance issues, bug fixes, new feature implementations, and strategic decisions for the language's future. Below are the key highlights:

• Package Server Performance:

  • Users reported slow WDL downloads and uploads, which was acknowledged by Wayne, who promised a server restart to address the issue.

• Overload Rules and Type Conversion:

  • A discussion on overload rules revealed issues with Long/LongLong overloads. Wayne clarified that exact matches are preferred, and type conversion may be necessary to resolve conflicts.

• Option Strict and Implicit Conversions:

  • The community discussed the potential benefits of implementing an Option Strict-like feature to avoid implicit conversions, which can lead to unexpected behaviors.

• Function Signature Issues:

  • Wayne addressed a reminder about function signature issues for mouseup and mousedown events, confirming that the issue was resolved.

• Stack Trace at Runtime:

  • Wayne confirmed that a proper stack trace is possible at runtime using the vbWatchdog feature, which allows reading the call stack upon handling an unhandled error.

• Code Signing Certificates:

  • Users discussed issues with renewing code signing certificates from kSoftware, sharing experiences and alternative solutions.

• New Features and Bug Fixes:

  • Wayne expanded the functionality of [PreserveSig(False)] for user-defined APIs, which was acknowledged and appreciated by the community.

• SolidWorks API Integration:

  • A new user inquired about using twinBASIC for SolidWorks automation, leading to a detailed discussion on the feasibility and benefits of using twinBASIC over other languages like VB.NET, C#, and Python.

• twinBASIC for Applications (TBA):

  • Wayne shared a video demonstrating a Proof of Concept for "twinBASIC for Applications," which aims to replace the VBA SDK. This sparked excitement and further questions about its capabilities and legal implications.

• Compiler Warnings and Strictness Options:

  • New compiler warnings (TB0018, TB0019, TB0020) were introduced to enforce stricter type conversions, which can be enabled in project settings. These warnings aim to prevent implicit narrowing conversions, implicit enumeration conversions, and suspicious interface conversions.

• Community Polls and Feedback:

  • Wayne encouraged the community to participate in polls to gather feedback on new features and improvements.

In summary, this week saw significant progress in addressing performance issues, enhancing type safety, and expanding twinBASIC's feature set. The introduction of "twinBASIC for Applications" marks a major milestone, promising a modern alternative to the VBA SDK. The community remains engaged and collaborative, contributing to the continuous improvement of twinBASIC.

Around the Web

Memory List Manager

The latest project from fafalone is here, as announced in Discord:

Memory List Manager is a small, lightweight utility to clear standby memory and flush caches, without needing to load a full heavyweight system resources app like SystemInformer, the code for which this project is based on. Windows keeps memory contents it thinks you might use again soon loaded and marked as standby, theoretically this memory is 'available' but memory management isn't always perfect, and high persistent standby and especially modified memory can cause reduced system performance, certain issues with some memory intensive apps or even lead to spurious out of memory errors and system destabilization.

This was built entirely in tB, without concern for VB6 compatibility so it takes advantage of many new language features. tB Beta 553 or newer is required, since this uses the latest WinDevLib version which requires the Alias edge case fix in that release.

See repo for more information on commands and usage.

TabOrder Addin for twinBASIC

If fafalone is the undisputed king of twinBASIC sample projects, sokinkeso has earned that title when it comes to twinBASIC IDE addins.  And this one has the potential to be a real time saver.  Here's the announcement from Discord:

As I have announced earlier, I was developing a TabOrder addin for twinBasic.
Last month I was straggling to find time to roll out a BETA release and finally it is in a pretty stable state.
Also, I have to tag this project as EXPERIMENTAL, because it uses some unsupported (officially) techniques to achieve its goal.
In its final release , some parts of the code will be re-written, and then I will upload this addin to github.
After many tests, I feel it's safe to share this with you, so anyone can try it and make any suggestions.
But as it is still in BETA state,  start your tests with new small projects.
You can find a Readme file in the zip, for more details.

The zip file can be downloaded from Discord here.

Changelog

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

ChatGPT Changelog Summary

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

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

• Improved IDE Visuals and Functionality: The IDE's object-view PROJECT EXPLORER icons have been updated for better visual clarity, and old-style VB attributes now have semantic highlighting for improved readability.
• Enhanced Error Detection and Conversion Hints: New hints (TB0018, TB0019, TB0020, TB0021) have been introduced to detect implicit narrowing conversions, enumeration conversions, and suspicious interface conversions, with options to enforce strict mode for better code safety.
• Support for Explicit Conversions: The CType(Of T) conversion function has been added, aiding in explicit conversions to custom types and complementing the new hint system.
• Internal Refactoring for Future Features: Significant internal refactoring has been done to pave the way for host-embedded projects, such as 'twinBASIC for Applications'.
• Strictness in Built-in Packages: All built-in packages have been updated to enforce the new strictness levels, helping identify subtle bugs and performance issues.

WARNING: The following issues are present in BETA builds 546 - 557 (the latest build as of publication):

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

BETA 548

• added: (IDE) sokinkeso tweaked the icons for object-view PROJECT EXPLORER [ sokinkeso, discord ]
• fixed: (IDE) some issues with virtual panel scroll bars [ fafalone, discord ]

BETA 549

• fixed: ActiveX/UserControl handling of InPlaceDeactivate for supporting UserForm MultiPage control [ Tecman, discord ]
• fixed: (IDE, regression in BETA 547) debug message box appears when using the old Find-in-files feature (CTRL+F)

BETA 550

• fixed: some quirks with the object-view mode

BETA 551

• fixed: (regression in BETA 550) IDE devtools window opens alongside the IDE

BETA 552

• fixed: some issues when control width/height are set to zero [ vbuser, discord ]
• fixed: CheckBox.Click event did not fire when CheckBox.Value was set programmatically [ Tecman, discord ]

BETA 553

• fixed: edge case of 'duplicate definition in the current scope' error occuring with some use of PreserveSig attribute on API Declares [ fafalone, discord ]
• fixed: PreserveSig(False) attribute support in type library viewer [ fafalone, discord ]

BETA 554

• improved: old-style VB attributes are now coloured grey for semantic highlighting to match tB native attributes
• changed: lots of internal refactorings to support the effort for host-embedded projects ('twinBASIC for Applications')
• fixed: form designers lose their state when a compiler restart occurs [ fafalone, discord ]

BETA 555

• fixed: IDE toolbar Continue/Pause/Stop button disable state would be incorrect when an unhandled error is encountered
• fixed: IDE toolbar Stop button would often be disabled inappropriately
• fixed: renaming/moving files in the IDE PROJECT EXPLORER panel would often cause compilation problems requiring a restart of the compiler

BETA 556

• added: hint TB0018 "Implicit Narrowing Conversion" - default level IGNORE, change to ERROR level to enforce "Strict" mode
• added: hint TB0019 "Implicit Enumeration Conversion" - default level IGNORE, change to ERROR level to enforce "Strict" mode
• added: hint TB0020 "Suspicious Interface Conversion" - default level IGNORE, change to ERROR level to enforce "Strict" mode
• added: CType(Of T) conversion function for supporting explicit conversions to custom types (useful in relation to TB0018/TB0019/TB0020)
• improved: all built-in packages updated to enforce strictness (TB0018/TB0019/TB0020), helping identify some subtle bugs and performance issues

BETA 557

• fixed: some bugs with regards to project settings for warning levels [ fafalone, discord ]
• changed: tamed TB0018 for cases when implicitly converting a numeric literal to a narrower type [ fafalone, discord ]
• added: hint TB0021 "Implicit Enumeration Conversion With Numeric" - default level IGNORE, change to ERROR level to enforce "Strict" mode [ fafalone, discord ]