twinBASIC Update: September 8, 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 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:

• 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

New Releases Improve Performance and VBx Compatibility

After a several-week hiatus, Wayne released several new versions of twinBASIC over the past seven days.

Despite the recent build-up, there were no major new language features. Instead, the focus seemed to be largely on the inner workings of twinBASIC itself.

Here was Wayne's accompanying announcement in Discord:

BETA 593 is out. No single big feature, but lots of important tech debt paid off.
Still feeling rubbish with this sinusitis, so releases won't be back to normal yet, sorry.

Paying off technical debt helps ensure the project's long-term success, but it's a bit like your NFL team drafting an offensive lineman with their first pick: it may be the best choice, but it's still not very exciting.

Here's a short list of some of the important technical debt that got paid down with these recent releases:

• Significant rewrite of the form engine's internal C++ and twinBASIC code interaction, improving efficiency and fixing numerous issues
• Complete overhaul of form and control loading/unloading mechanisms to better align with VB6 and VBA behaviors
• Rewritten IDispatch implementation for improved performance in late-bound code against twinBASIC classes
• Optimization of ActiveXControlExtender code generation, reducing output file sizes for projects using multiple ActiveX or UserControls
• Refinement of exposed control methods, tidying up internal members for better IntelliSense experience
• Reworking of form dimension handling, including proper accounting for window area vs. client area and standardizing size properties to use twips

The fixes focused mostly on performance and VBx compatibility improvements.

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 general channel transcript for the week of September 3-7, 2024:

The twinBASIC team continued to make progress on the language and development environment, with several beta releases and bug fixes. Here are the main highlights:

• BETA 593 was released, focusing on paying off technical debt rather than introducing major new features.

• BETA 595 included a refactoring of ActiveXControlExtender, resulting in reduced RAM usage in the IDE when working with multiple ActiveX/UserControls.

• The property sheet in the IDE was updated in BETA 596 to include category groupings, improving organization and ease of use.

• A critical bug in BETA 597 that prevented creating new projects was quickly identified and fixed in BETA 598.

• BETA 599 addressed an issue with frame controls in forms losing their background color when reopened in Excel ActiveX DLLs.

• The team continued to work on VB6 compatibility, with ongoing discussions about implementing features like LINQ and lambda functions in a BASIC-friendly way.

• There were conversations about text encoding in twinBASIC, clarifying that source files are saved in UTF-8 for .twin files and ANSI for .bas and .cls files.

• The lack of support for external source files was noted as a current limitation, with plans to implement this feature for version 1.0.

• Developers discussed techniques for creating small executables, with one experiment producing a 4KB file by customizing the entry point and removing unnecessary elements.

In conclusion, the twinBASIC team demonstrated their commitment to rapid development and bug fixing, with multiple beta releases in a single week. The focus on improving the IDE's usability and addressing compatibility issues shows a dedication to creating a robust and user-friendly development environment for BASIC programmers.

Around the Web

ActiveX Being Disabled in Non-Access Apps in Office 2024

OVer in the Off-Topic channel of the twinBASIC Discord server, Wayne posted a link to this article announcing Microsoft's plans to disable ActiveX controls in Word, Excel, PowerPoint, and Visio beginning with Office 2024:

ActiveX will be disabled by default in Microsoft Office 2024 - M365 Admin

ActiveX will be disabled by default in Office 2024, affecting Word, Excel, PowerPoint, and Visio. This change occurs in October 2024 for Office 2024 and begins in April 2025 for Microsoft 365 apps. Users can re-enable ActiveX by adjusting Trust Center Settings, the registry, or group policy settings. We’re making some changes to the handling of ActiveX objects in the Microsoft Office client apps. Starting in new Office 2024, the default configuration setting for ActiveX objects will change from Prompt me before enabling all controls with minimal restrictions to Disable all controls without notification. This change applies to the Win32 desktop versions of Word, Excel, PowerPoint, and Visio. When this will happen: For new Office 2024, this change will happen immediately when it’s released in October 2024. For Microsoft 365 apps, this change will rollout in stages beginning in April 2025. How this will affect your organization: Users will no longer be able to create or interact with ActiveX objects in Office documents when this change is implemented. Some existing ActiveX objects will still be visible as a static image, but it will not be possible to interact with them. In non-commercial SKUs of Office, users will see this notification when an ActiveX object is blocked by the new default behavior: The new default setting is equivalent to the existing DisableAllActiveX group policy setting. What you need to do to prepare: When this change takes effect, if you need to use ActiveX controls in Office documents, you can change back to the previous default behavior using any one of the following methods: In the Trust Center Settings dialog, under ActiveX Settings, select the Prompt me before enabling all controls with minimal restrictions option. In the registry, set HKEY_CURRENT_USER\Software\Microsoft\Office\Common\Security\DisableAllActiveX to 0 (REG_DWORD). Set the Disable All ActiveX group policy setting to 0. Message ID: MC884011 Related

M365 Admin

The following short conversation ensued:

[Wayne]: MS continuing to strip things down in an effort to reduce areas that are ripe for malicious attack. How long will 32-bit processes be supported for, one has to wonder. Reducing the OS to just 64-bit would likely make business sense for them IMO.

[Gary Miller]: So TwinBasic may be the only cost effective way for companies to migrate their VB6 application to 64 bit if that happens right? Sound like Microsoft is creating a large market for you?

[Wayne]: I suspect we're still a few years off from seeing 32-bit removed, but in my opinion, and given the current direction from Microsoft of late, I certainly wouldn't be surprised if it's being planned. Yes, tB should be in a good place by then

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.

GitHubWaynePhillipsEA

AI-Generated Changelog Summary

^{* Auto-generated via Claude-3.5-Sonnet, sorted in order of its opinion of "most impactful changes."}

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

• Improved form engine performance: Significant rewrite of the form engine's internal C++ and TB code interaction, resulting in greater efficiency and numerous bug fixes.

• Enhanced IDispatch implementation: Rewritten for better performance in late-bound code against twinBASIC classes.

• Form and control loading/unloading rework: Completely revamped to better match VB6 and VBA behaviors, including fixes for runtime control addition and form dimension handling.

• Reduced code generation size: Optimized ActiveXControlExtender codegen, resulting in smaller output files for projects using multiple ActiveX or UserControls.

• Form designer enhancements: Added group categories to the property sheet and fixed various issues related to control resizing and behavior in the designer.

• Breaking change: Form MinWidth, MinHeight, MaxWidth, and MaxHeight properties now use twips instead of pixels, potentially requiring code adjustments.

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

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

BETA 593

• fixed: Slider.ToolTipText property was missing
• fixed: UpDown.ToolTipText property was missing
• fixed: missing 'Programmable' registry entry for COM registered classes [ https://github.com//issues/1891 ]
• fixed: some ITypeInfo edge cases, causing Excel UDFs to fail [ https://github.com//issues/1891 ]
• fixed: hard compiler crash when using CurrentComponentCLSID inside a Const expression [ https://github.com//issues/1888 ]
• improved: IDispatch implementation has been rewritten offering much better performance for late-bound code against tB classes
• improved: big rewrite of how the form engine internal C++ and TB code interoperate allowing for much greater efficiency. Lots of issues identified and fixed. Likely some regressions.
• improved: tidied up all exposed control methods so that internal members are no longer exposed on the outermost class (better intellisense)
• added: Class.BeforeFirstMethodAccess event (used internally for simplifying handling of EnsureFormIsLoaded)
• fixed: UserControls in the form designer could cause the IDE to lose focus
• fixed: completely reworked form and control loading/unloading to better match VBx behaviours
• NOTE: CustomControls samples are broken in this release
• NOTE: There may be some regressions in this build

BETA 594

• fixed: (regression in BETA 593) AX/UserControls that auto-resize themselves (e.g. VBCCR.MonthView) were not resizing inside the form designer
• fixed: (regression in BETA 593) CustomControls samples were broken

BETA 595

• improved: reduced codegen size of ActiveXControlExtender where multiple Ax/UCs are used in a single project (e.g. PhotoDemon down from 38MB to 28MB)
• fixed: controls added at runtime via Controls.Add now have implicit width/height, if not overriden, to match VBx
• improved: simplified control instantiation and serialization by removing specialized constructor Sub New(Serializer)

BETA 596

• fixed: Form.Width and Form.Height runtime values now correctly account for the window area rather than the client area
• fixed: Form.MinWidth/MinHeight/MaxWidth/MaxHeight properties are now expressed in twips rather than pixels [ https://github.com//issues/1836 ]
• note: BREAKING CHANGE if you modify MinWidth/MinHeight/MaxWidth/MaxHeight at runtime, you might need to adjust the code to take account of twips
• improved: form designer property sheet now has group categories

BETA 597

• This version removed due to hard crash whenever opening form designer.

BETA 598

• fixed: (regression in BETA 597) opening any form designer would cause a hard crash in the compiler process

BETA 599

• fixed: (regression in recent betas) Frame control BackColor not correct after unloading and reloading a form [ woeoio, discord ]

BETA 600

• fixed: codegen edge case for when comparing two Single datatype values [ wayaya30, discord ]

BETA 601

• fixed: (regression) Frame controls producing some spurious debug messages in the DEBUG CONSOLE