twinBASIC Weekly Update

twinBASIC Update: January 15, 2023

Highlights include a new VBCCR-based GUI project type, a VBCCR TWINSERV package, and a discussion about support for block-level scope in twinBASIC.

Mike Wolfe

• 7 min read
twinBASIC Update: January 15, 2023

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:

Highlights

Experimental VBCCR Package Now Available

In BETA 228, Wayne added the VBCCR 32-bit UserControl package to TWINSERV (the twinBASIC package manager).  This package is a straight import of VBCCR v1.7.45 from its VBP source (hence the current 32-bit only restriction).

If you're not familiar with it, VBCCR is Kr00l's replacement project for the Microsoft Common Controls library (VBCCR => Visual Basic Common Controls Replacement).  A description of the project along with version history is available at this vbForums post: CommonControls (Replacement of the MS common controls).

The original VB6 VBCCR project is a complete replacement for the following Microsoft libraries:

  • MSCOMCTL.OCX
  • MSCOMCT2.OCX
  • RICHTX32.OCX
  • COMDLG32.OCX
  • COMCT332.OCX
  • MCIWNDX.OCX (shipped with VB5)
  • SYSINFO.OCX

The VB6 VBCCR project provides the following controls (I assume these are all available in the twinBASIC VBCCR package, but I have not confirmed):

- Animation
- CheckBoxW
- ComboBoxW
- CommandButtonW
- CommandLink
- CoolBar
- CommonDialog (Class Module)
- DTPicker
- FontCombo
- FrameW
- HotKey
- ImageCombo
- ImageList
- IPAddress
- LabelW
- LinkLabel
- ListBoxW
- ListView
- MCIWnd
- MonthView
- OptionButtonW
- Pager
- ProgressBar
- RichTextBox
- Slider
- SpinBox
- StatusBar
- SysInfo
- TabStrip
- TextBoxW
- ToolBar
- TreeView
- UpDown
- VirtualCombo
- VListBox

Additionally, there is a new project type of "Standard EXE (plus VBCCR) - experimental" so that you can easily play around with the VBCCR UserControls in twinBASIC.

Beyond the availability of the VBCCR package itself, this release is important for at least two other reasons:

  1. It shows how much progress twinBASIC has made in terms of VBx UI compatibility
  2. It serves as a proof-of-concept for including other third-party controls and tools in the twinBASIC ecosystem, even (or especially) those from the VB6 world

Many a promising programming language has come and gone over the years not because of any problem with the language itself but because of the lack of a community and third-party tool ecosystem.  The inclusion of a third-party package in advance of a version 1.0 release portends well for twinBASIC.

VBCCR Usage Details

Wayne provided additional usage tips on the twinBASIC Discord server:

There is now a package available in TWINSERV for VBCCR.  It's the unaltered v1.7.45 source as available via Krools github page.   To use it, add the package via the TWINPACK list, and make sure it is ordered ABOVE the WinNativeForms reference, like this:
This package only works with BETA 228 onwards.  There is also a new project type available that already has the package referenced:
There is still much work to do to get VBCCR completely working, but all controls do "work" at this point (work == renders).   You may note that because the controls are distributed via a package which gets compiled only once when loading the project, it makes working with the controls in the form designer much quicker than the previous ComCtlsDemo project I uploaded (no hangs/freezes).

Around the Web

A Note About Recent Development Priorities

Over on Discord, someone mentioned that a lot of recent development seemed to be focused on the unrelated VBCCR project.  I suspected this had less to do with VBCCR specifically, and more to do with the fact that Wayne was looking to smoke out as many edge cases as possible while working on user control support.  Wayne confirmed that thought in his response:

It may seem that I am concentrating on VBCCR, but that is not the case.   I am focusing only on UserControl support, and VBCCR just happens to be a very good test bed for UserControls.   There is still some important work to be done on UserControls as it's such a big area, so please bear with me.  It just doesn't make sense to come off the UserControls work right now as it's very complex and is fresh in my mind.  Another couple of weeks and I'll hopefully be back on the remaining missing UI features (not Printer for a while though).

Do activex dlls support standard modules or just classes?

Good discussion over on GitHub about exposing and calling standard module procedures from twinBASIC ActiveX libraries:

Is it possible to call functions in standard modules of an activex dll, or do we need a 3rd build type "COM DLL" for that? I.e. ActiveX is just defining objects you can New up?

Ben Clothier offers one solution:

If you decorate a function with DllExport attribute, then you can use the DLL without referencing it.

He also includes a link to his 7zip twinBASIC project that contains a sample of such usage:

    [ DllExport () ]
    Public Function GetArchiveFactory() As Object
        Return New ArchiveFactory()
    End Function

Wayne Phillips offers another suggestion:

A more COM friendly approach might be to use an [AppObject] class, which is basically like a predeclared class where you don't need to qualify its methods... So you can call just DoSomething on class Foo without the Foo. prefix.

Support for Block-Level Scope in twinBASIC

I opened a GitHub discussion on this topic: Add support for block-level scope.

For a brief primer on block-level scope (and VBA's current lack of support for it), see here: Block-Level Scope in VBA...Does Not Exist

My question is, should we add such support to twinBASIC?

I suggested reusing the Private keyword to explicitly enable the feature:

Sub TestBlockScope()
    If True Then
        Private foo As Long
    End If
    Debug.Print foo  '<-- This would raise a compile error such as,
                     '    "'foo' is inaccessible due to its protection level"
End Sub

I'd love to hear your thoughts on the topic over on GitHub.

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

WARNING: The following two issues are present in BETA builds 202 - 232 (the latest build as of publication):

  • building ActiveX controls is known to be broken in these builds.  Use BETA 201 instead for that feature.
  • there are known memory leaks in these versions, so memory usage will be higher than normal

BETA 225

  • fixed: several IDE memory leaks (further work still to do in this area)
  • improved: stability with regards to global variables initialization/cleanup

BETA 226

  • fixed: (regression) issues editing forms where changes were not being reflected in builds [ AlienSoft, discord ]
  • improved: switching to SafeMode now retains the PROBLEMS panel data to aid in tracking down compiler issues [ wqweto, discord ]
  • fixed: imported controls property-bag error handling default-value objects [ fafalone, discord ]
  • fixed: UserControl.Initialize not firing for imported controls [ fafalone, discord ]
  • fixed: Standard DLL builds no longer include DllCanUnloadNow/DllGetClassObject/DllRegisterServer/DllUnregisterServer unnecessarily [ sokinkeso, discord ]
  • fixed: {Object}.Print statement would cause codegen crash in some instances [ kimpos, discord ]
  • fixed: edge case where a class field array declared with As-New semantics could cause compiler crash during code editing [ kimpos, discord ]

BETA 227

  • fixed: datatype with the same name as container library would cause ambiguity errors [ kimpos, discord ]
  • fixed: some array definitions in generated type libraries would not be usable from VB/VBA [ kimpos, discord ]
  • fixed: (regression) IDispatch implementation of Err could crash in generated builds [ https://github.com//issues/1454 ]
  • improved: form designer toolbox icons transparency is now effective [ wqweto, discord ]

BETA 228

  • fixed: some internal PixelsWidth/Height handling and Paint event handling to fix VBCCR.CoolBar UserControl
  • fixed: non-visual UserControls now show their icon in the form designer placeholder boxes
  • fixed: packages of controls are now allowed, but the package reference must be ordered BEFORE WinNativeForms in the references list
  • added: VBCCR 32-bit experimental UserControl package to TWINSERV (unaltered version of VBCCR v1.7.45 from VBP source)
  • added: new project type of Standard EXE (plus VBCCR) - experimental (32-bit only) for trying out VBCCR UserControls in tB

BETA 229

  • improved: initial overhaul of control repainting/resizing for all types of controls

BETA 230

  • fixed: form property sheet now respects FUNCFLAG_FNONBROWSABLE(0x400) when set via VB_MemberFlags [ Krool, discord ]
  • fixed: Picture and Font objects of UserControls and ActiveX controls gone AWOL in recent builds
  • fixed: form designer color picker popup window can extend past the IDE window [ DinyaZ, discord ]
  • improved: added support for IPerPropertyBrowsing (VBCCR.MousePointer now shows correctly in the form designer)
  • fixed: some edge cases around UserControls reading internal UnitPixelScale
  • fixed: InputB() now allows optional # file prefix character before the file number [ https://github.com//issues/1458 ]

BETA 231

  • fixed: (regression) UserControl Resize event wouldn't always fire in design mode [ sokinkeso, discord ]
  • fixed: child window redraw issue when picture box is partial covered [ fafalone, discord ]
  • fixed: ActiveX initialization ordering issue [ fafalone, discord ]

BETA 232

  • fixed: problems with fixed-length arrays and as-new semantics [ kimpos, private ]
  • improved: reporting of missing project references are now reported via modal message box
  • fixed: user-defined events are now suppressed during UserControl.ReadProperties [ fafalone, discord ]
  • improved: tweaked the VARIABLES panel layout to better cope with data that is too large to fit
  • improved: tweaked the monaco selected text highlighting z-order so that selected text is more noticable when debugging
  • improved: tweaked IDE modal dialog CSS for less rounded look

Never miss an article.

Sign up to receive a Sunday morning email with links and recaps of the seven articles published that week.
(I'll never sell your email. Unsubscribe any time.)


All original code samples by Mike Wolfe are licensed under CC BY 4.0