twinBASIC Weekly Update

twinBASIC Update: July 17, 2022

Highlights include double-click to change form/control properties in the IDE, support for the Form.Show Modal argument, and a discussion about On Error Resume Next.

Mike Wolfe

Jul 17, 2022 • 5 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, 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)

Highlights

Double Click Property Name to Cycle Through Values

A single click on a dropdown value (such as vbDefault in the screenshot below) will open the dropdown box. This is better than having to try to hit the tiny triangle on the right side of the box as is required in Access. This becomes a problem, though, when a double-click changes the property value in a dropdown. If you clicked a dropdown value two times in a row, the behavior of the IDE varied depending on how close together those two clicks were:

Double-click: cycled to the next value
2 single clicks: opened and closed the dropdown box

To avoid this issue, Wayne removed the double-click behavior from the property value and switched it to the property name.

For example, instead of double clicking on "vbDefault" in the screenshot below, one would double click on "MousePointer" to cycle among the various values (vbArrow, vbCrosshair, etc.).

Breaking Change to Form.Show from Earlier tB Builds

Wayne explains in the discussion for BETA 72:

fixed: Form.Show now offers the Modal argument. Modeless is not yet supported, so vbModal must now be explicitly passed here.

Apologies as the change to Form.Show is a breaking change in tB, but of course needed for backwards compatibility with VBx. I should've added the parameter from the start regardless of not supporting modeless forms. If you now just call Form.Show(), it will raise an error as we don't yet support modeless forms. Change all uses to Form.Show(vbModal) to fix it.

In addition, I'm expecting a few regressions in this release, since there were significant changes to the form Load/Unload routines to match VBx. But the compatibility is improved, so for instance you can now Unload a form and reuse the same form instance, just like in VB6.

To summarize, this change furthers the 100% VBx compatibility goal. It breaks backward compatibility with earlier releases of twinBASIC, which were less compatible with VBx.

Around the Web

Warn About Dangling "On Error Resume Next" Calls?

Ben Clothier proposed adding some code analysis to identify On Error Resume Next lines that do not include matching On Error Goto 0 or On Error Goto {LabelName} lines:

IMNSHO, a OERN without a balancing OER* is smelly and may require some attention. One downside is that it may be annoying for certain classes of functions that exist to swallow errors. However, there are interesting side-effects from having a dangling OERN. To illustrate:
Public Sub Main()
  Donk
  Debug.Print Err.Number 'Prints 11?!?
End Sub

Private Sub Donk()
  On Error Resume Next
  Debug.Print 1 / 0
End Sub

I'll be honest and admit that I did not know that the error number would propagate out of the Donk procedure in Ben's code example. I would have considered it "handled" (i.e., ignored) in the Donk procedure by virtue of the On Error Resume Next line and that the error object would be cleared when the routine terminated. Of course, the Err object is global, so I suppose that makes sense. I guess it's something I've never really thought about...

As for the warning itself, I don't have a strong opinion. I think it makes sense to include it. OERN is one of the most abused (and misunderstood) features of VBA, so if the presence of a compiler warning forces new developers to think through how they are using it, that would be a good thing. On the other hand, too many compiler warnings will likely have the effect of conditioning new developers to simply ignore anything that's not an actual error.

In other words, I support it based on a "reducing unknown unknowns" rationale, but object to it on "signal vs. noise" grounds.

Changelog

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

BETA 76

fixed: edge cases around dynamic arrays of UDTs in Get/Put statements [ baka, discord ]

BETA 75

fixed: handling of uninitialized arrays in Get/Put statements [ baka, discord ]
fixed: Go to definition not working with Implements-Via imported members [ https://github.com//issues/972 ]

BETA 74

fixed: (regression) F5/Start fails if the startup object is a form due to change in vbModal requirement [ https://github.com//issues/987 ]
improved: double-click handler for property sheet values moved to the property caption double-click handler instead [ https://github.com//issues/946 ]
fixed: codegen crash in some instances [ baka, discord private ]

BETA 73

fixed: (regression) Collection class members being treated as late-bound (dispinterface) in BETA 72

BETA 72

fixed: unary operator detection involving Case and line labels was sometimes incorrect [ https://github.com//issues/969#issuecomment-1179674485 ]
fixed: built-in enumeration priority order (...vbNormal is ambiguous conflict) [ https://github.com//issues/718 ]
added: Globals.Unload() support [ https://github.com//issues/783 ]
improved: overhauled the form Load/Unload routines to better match VBx
fixed: Form.Show now offers the Modal argument. Modeless is not yet supported, so vbModal must now be explicitly passed here.

BETA 71

fixed: (regression) calling Class_Initialize directly was failing [ https://github.com//issues/969#issuecomment-1179674485 ]
fixed: parameters that are arrays of fixed-length strings are now allowed [ https://github.com//issues/969 ]
fixed: OptionButtons now respect their Value as set in the IDE form designer [ https://github.com//issues/978 ]
fixed: OptionButtons exclusive values are now respected in the IDE form designer [ https://github.com//issues/978 ]
fixed: WithEvents reference problem causing double-free at compile-time
fixed: all real (VBA6.DLL) VBA library elements now forward to the tB internal versions, allowing the IDE to avoid loading VBA6.DLL when a referenced project exposes something from the VBA module [ https://github.com//issues/974 ]