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 (NOTE: the twinBASIC VSCode extension is under a feature freeze until 2023)
- GitHub Issue Tracker (report bugs)
- twinBASIC Discord Server (chat about the project)
Double-Click to Change Property Values in IDE
The tB IDE now supports double-clicking to change the values of properties (e.g., to pick the next option from a dropdown).
There is one caveat as Kr00l pointed out:
In tB the drop-down is opened after a click, so a double-click can accidentally happen if the closing attempt is too quick.
In VBx the drop-down field only opens when clicking on the arrow button.
Here are two sample screen recordings from Kr00l:
Kr00l makes a good point. This is the sort of thing that users could easily do accidentally and then wonder how their property value suddenly changed.
That said, I don't think the VBx approach of making developers hit a tiny, little target area to open the dropdown is the right solution, either. I mean, if you're a long-time reader you may already know my feelings on Combo Boxes and Target Sizes. I go to some lengths to increase the default target area of the combo boxes I use in my own applications.
As an alternative, I proposed moving the double-click handler from the property value to the property name.
For example, instead of double-clicking on "vbDockNone" to switch it to "vbDockLeft", the developer would double-click on "Dock." Every time they double-clicked on the property name, it would cycle to the next available property. Double-clicking on the property value would have no effect other than to open and close the dropdown box.
End Statement Support
BETA 65 added support for the
End statement. The
Unload statement has not been implemented yet.
Shape Control Added
As of BETA 67, you can now add shape controls to your twinBASIC forms.
The following shapes are currently supported:
- Rounded Rectangle
- Rounded Square
Around the Web
Using ByVal in Parameter of a Function Call?!
This may be a bit off-topic as it's not a twinBASIC discussion per se, but it answered a question I've had for a long time about the origins and behavior of the
As Any syntax that you see with some API declarations.
Set Condition = UIA.CreatePropertyCondition(UIA_NamePropertyId, ByVal "Compact and Repair Database")
I know about using ByVal/ByRef on the parameters in a function DEFINITION....but to use them during a function CALL like this??!?
I had no idea that VBA supported or tolerated something like this!?
Neither did I, to be honest.
Apparently, the syntax relies on a parameter being declared
As Any within an API declaration.
Vladimir Vissoultchev (a.k.a., wqweto) provides some additional context:
As Anyparameter (so called
void *in IDL) you can use ByVal/ByRef modifier at callsite.
Let me make it clear: No you cannot change ByVal/ByRef at callsite unless calling an API declare with
As Anyparameter or calling method on an interface with
void *parameter from a typelib.
Here is a recent discussion on ByVal vs ByRef.
Here are the updates from the past week. You can also find this information by visiting the GitHub twinBASIC Releases page.
- added: Shape control (currently not windowless) [ https://github.com//issues/938 ]
- fixed: several ActiveX tab-key related issues [ https://github.com//issues/935 ]
- fixed: form designer duplicate/paste issue with the naming of the new controls [ https://github.com//issues/957 ]
- improved: better error handling around quarantined IDE executable files [ https://github.com//issues/929 ]
- fixed: form resize IDE background issue [ https://github.com//issues/954 ]
- fixed: form designer control rendering causing window flashes [ https://github.com//issues/953 ]
- fixed: regression, clicking on an option button within a form containing non-visual controls caused a crash [ https://github.com//issues/952 ]
- fixed: binding to Left() in forms where there is a conflicting Left property, by using a new attribute
BindOnlyIfNoArgumentson the Left property definition [ https://github.com//issues/511#issuecomment-1169000449 ]
- added: initial implementation of End statement [ https://github.com//issues/783 ]
- improved: faster and more accurate form controls layout engine [ https://github.com//issues/949 ]
- fixed: FreezeEvents timing problem [ https://github.com//issues/941 ]
- fixed: Is-operator problem in treatment of Variant-Empty [ https://github.com//issues/943 ]
- fixed: issues with programmatically changing OptionButton values [ https://github.com//issues/940 ]
- fixed: tab issues with frames/containers [ https://github.com//issues/940 ]
- fixed: ActiveX property updates not always immediately effective [ https://github.com//issues/945 ]
- fixed: Save Project menu options weren't forcing dirty editors to save, making it ineffective until the Save button on the toolbar was clicked [ https://github.com//issues/947 ]
- improved: form property sheet now allows double click on enumerations to switch to the next value [ https://github.com//issues/946 ]