twinBASIC Weekly Update

twinBASIC Update: May 6, 2024

Highlights include support for the [NonBrowsable] attribute for ActiveX controls and discussions on Implements Via and ByVal/ByRef for tB vs. VB6 events.

Mike Wolfe

May 6, 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, 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

Support Added for `[NonBrowsable]` Attribute on ActiveX Control Properties

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

The latest update to the twinBASIC programming language introduces support for the [NonBrowsable] attribute, which can be applied to properties of ActiveX controls. This attribute is equivalent to setting the VB_MemberFlags attribute to "400" or using the "Don't show in Property Browser" option in VB6.

When applied, the [NonBrowsable] attribute hides the tagged property from appearing in the properties browser or property sheets of the ActiveX control, while still allowing it to be visible in the object browser and accessible via code. This provides finer control over the visibility of properties compared to the existing [Hidden] attribute, which hides the property entirely from both property browsers and intellisense. Developers can now choose to selectively hide certain properties from the property sheet that the end user sees, while still keeping them available for programmatic access.

Discord Chat Summary

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

Summary of twinBASIC Discord Conversations - April 27-30, 2024

This past week, the twinBASIC Discord server saw discussions around integrating AI chat capabilities into twinBASIC applications using the Dllama library. Developers encountered some challenges but made good progress.

Key points from the conversations:

The Dllama library allows any BASIC dialect that supports calling DLL functions to integrate local AI models like gguf for chatbot functionality. This is done using a single inference function.
Initial attempts to use Dllama in twinBASIC ran into issues where it worked in the IDE but not in compiled executables. The app window was also closing unexpectedly.
Investigation revealed the compiled app couldn't find the required models.json file due to differences in the current working directory between the IDE and compiled app. This was resolved by explicitly setting the current directory.
Another roadblock was twinBASIC not setting the Large Address Aware (LAA) flag for 64-bit builds, which Dllama requires to allocate enough memory. This was fixed in twinBASIC build 527.
With these two fixes, a proof-of-concept twinBASIC app was able to successfully use Dllama to get responses from a local gguf AI model.

' Example of calling Dllama inference function
lpRet = LLM("C:\LLM\gguf\", "models.json", "phi3:4B:Q4", 0, 1024, 27, Text1.Text)

In summary, while integrating the Dllama AI library presented some initial hurdles, the twinBASIC community worked together to identify the root causes and implement solutions. Being able to easily add local AI capabilities to twinBASIC apps is an exciting development. The core twinBASIC devs were also quick to resolve a key issue around the LAA flag for 64-bit support.

Around the Web

Implements Via not allowing member override

^{The following is an AI-generated summary of the key points from the GitHub discussion on issue #1840 in the twinbasic repo:}

The issue was opened by tdimitriou on May 1, 2024. It discusses a limitation with the Implements Via syntax in twinBASIC.
Originally, Implements Via allowed overriding any member of the base class directly, which made it easy to mimic inheritance. However, this capability was removed in a beta update over a year ago.
The expected behavior is that Implements Via should allow overriding any member, either directly or by introducing an Overrides keyword. Direct overrides were sufficient for most cases.
FullValueRider provided an updated code example showing the current way to override the Add method, by defining it as Public in the derived class.
tdimitriou clarified that they want a derived custom collection class to still be usable as the base Collection type, while allowing custom implementations that override base methods.
wqweto pointed out that not supporting Implements Interface.Method on Private methods for selective overrides with Implements Via is unfortunate, as it would make the feature more complete.
WaynePhillipsEA, a twinBASIC collaborator, confirmed that Implements Via was not designed to support overrides, as QueryInterface requests are passed to the base class directly. Proper inheritance support will be needed for this feature.
The issue was closed as "not planned" by WaynePhillipsEA on May 1, 2024.

In summary, while Implements Via is useful for mimicking inheritance, it currently does not support selectively overriding base class members. The twinBASIC team acknowledged this limitation and indicated that proper inheritance support in the future will be required to enable this capability. The workarounds for now are to either re-define methods as Public in the derived class or fall back to VBA-style manual interface implementation.

MouseMove Event in SStab Control Causes Crash

^{The following is an AI-generated summary of the key points from the GitHub discussion on issue #1835 in the twinbasic repo:}

Introduction

A recent GitHub issue thread in the twinBASIC project revealed a compatibility issue between how Visual Basic 6 (VB6) and twinBASIC handle the MouseMove event in the SStab control. The discussion uncovered some interesting behind-the-scenes behavior in VB6.

Key Points

Referencing the Button parameter passed to the SSTab1_MouseMove event handler causes a crash in twinBASIC, but works fine in VB6.
In VB6, the MouseMove event parameters are passed ByRef even though ByVal or ByRef is not explicitly specified. In twinBASIC, the parameters are passed ByVal.
Investigation revealed VB6 has a signature override for specific dispids. For MouseMove (dispid 0xfffffda2), it takes the ByVal parameter and turns it into ByRef behind the scenes. The reason for this is unclear.
To maintain compatibility, twinBASIC will need to replicate this behavior and reinterpret the parameters for not just MouseMove, but other events like Click, KeyUp, KeyDown etc.
There was also a mismatch discovered in the y parameter type - it's defined as Single in twinBASIC but as OLE_YPOS_PIXELS in the underlying ActiveX control. This needs to be reconciled.

Conclusion

The conversation highlights the challenges in maintaining full compatibility with VB6 while developing twinBASIC. Some of VB6's behind-the-scenes behavior, even if not well understood, needs to be replicated in twinBASIC for certain scenarios to work identically. The twinBASIC team will need to investigate further and implement the necessary signature overrides for the affected events. Collaboration between the developers and community members is helping uncover and resolve these compatibility issues as the project progresses.

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.}"

Added: New support for the [NonBrowsable] attribute, which prevents ActiveX control properties from appearing in property sheets, enhancing user interface customization.
Improved: Compatibility with VBA UserForms, now allowing twinBASIC-generated ActiveX controls to obtain tab focus, improving integration with existing VBA projects.
Fixed: Enforced Large Address Aware (LAA) flag in Win64 builds, removing memory usage restrictions and enhancing performance for larger applications.
Fixed: Ensured effectiveness of the [NonBrowsable] attribute in the VBA UserForm designer, even if not applied to the property-let method, ensuring consistent behavior across development environments.

WARNING: The following issues are present in BETA builds 424 - 5xx (the latest build as of publication):

there are known memory leaks in these versions, so memory usage will be higher than normal
see important release notes from BETA 424 here https://github.com/twinbasic/twinbasic/releases/tag/beta-x-0424

BETA 527

fixed: Win64 builds not enforcing LAA flag on built binaries, causing mem usage restrictions

BETA 528

added: support for attribute [NonBrowsable] (and equivalent of Attribute VB_MemberFlags = "400" / "Dont show in Property Browser" option) for ActiveX control properties from appearing in property sheets [ Tecman, discord ]
fixed: issue with VBA Userforms not allowing tB generated AX controls to obtain tab focus [ Tecman, discord ]

BETA 529

fixed: [NonBrowsable] flag not effective in VBA UserForm designer if not explicitly applied to the property-let method [ Tecman, discord ]