twinBASIC Weekly Update

twinBASIC Update: November 6, 2022

Highlights include native CoClass support and a TWINPACK package from fafalone with definitions for all the standard common controls.

Mike Wolfe

• 4 min read
twinBASIC Update: November 6, 2022

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

CoClass Support

For those of you interested in the advanced, low-level features of twinBASIC, direct support for CoClasses will be welcome news.  Personally, most of this stuff is way over my head, so I'll simply quote Wayne at length below:

The CoClass component type allows for the self-explanatory attributes of [CoClassId("")], [PredeclaredId], [AppObject], [Restricted] and [COMCreatable].  The attributes [Default] and [Source] are allowed on the Interface entries.  You must define one interface as [Default]:

[ CoClassId ("0BE35203-8F91-11CE-9DE3-00AA004BB851") ]
[ COMCreatable ]
CoClass StdFontCustom
    [ Default ] Interface stdole.Font
    [ Default, Source ] Interface stdole.FontEvents
    Interface stdole.IFont
End CoClass

In addition, and related to the question from @bclothier–["wouldn't we need the option to provide a custom implementation of the IClassFactory / IClassFactory2?"]–there is another attribute of interest:

[CoClassCustomConstructor("procName")]

By default, the construction of CoClass types is done through COM via CoCreateInstance as you'd expect.  If you want to override that behaviour, then you can provide the name of a custom constructor procedure here.    We are now using this for the VB.Global class, as can be seen in WinNativeForms package:

[ CoClassId ("FCFB3D23-A0FA-1068-A738-08002B3371B5") ]
[ CoClassCustomConstructor ("[_HiddenModule].CreateGlobalObject") ]
[ AppObject ]
Public CoClass Global
    [ Default ] Interface VBGlobal
End CoClass

With the above definition, when the Global class needs to be instantiated, the procedure [_HiddenModule].CreateGlobalObject is called.  This allows the compiler to provide the actual implementation of the coclass, rather than going through COM.   I'm sure some of you will find uses for this feature.  E.g:

[ CoClassId ("0BE35203-8F91-11CE-9DE3-00AA004BB851") ]
[ CoClassCustomConstructor ("COMStuff.CreateFontObject") ]
[ COMCreatable ]
CoClass StdFontCustom
    [ Default ] Interface stdole.Font
    [ Default, Source ] Interface stdole.FontEvents
    Interface stdole.IFont
End CoClass

Module COMStuff
    Public Function CreateFontObject(ByRef out As StdFont) As Long   ' HRESULT
        Debug.Print "StdFontCustom created..."
        Set out = New StdFont
        Const S_OK As Long = 0
        Return S_OK
    End Function
End Module

Forewarning:  over time, the CoClassCustomConstructor attribute might change, e.g. into a Sub New inside the CoClass syntax.  For the time being, this attribute is available in this form.

For those of you lost like me, Wayne provided a brief explanation of what CoClasses are in the twinBASIC Discord Server:

A CoClass can just be thought of as a regular class that you haven't implemented yourself.... it's one that is registered in the registry.  The CoClass definition tells us the GUIDs (CLSID and IIDs) that tell the compiler how to instantiate the class via COM, and how to consume them.

Global / App / Screen / Clipboard classes added to the WinNativeForms Package

Added as of Beta 166.

Around the Web

tbComCtlLib - Complete Common Controls definitions

Posted by fafalone on vbforums.com:

Almost all the work with API created Common Controls is from VB6 and only has x86 compatible definitions. But with twinBASIC being able to compile 64bit exes, it's time we had those definitions available in a x64 compatible form. I've gone ahead and done that. tbComCtlLib has all the standard common controls definitions, completed, with the major ones including additional undocumented definitions.

This is supplied as a TWINPACK Package you can add to your project in Settings->References. It will work with tbShellLib-- which is needed if you wish to use the RichEdit OLE Extensions.

This project is also on GitHub.

The package files are available for download at vbforums.com.

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

BETA 164

  • added: compiler warning TB0010: Duplicate DLL declaration detected
  • fixed: (regression) custom controls (WaynesButton etc) not working fully on Win32 architecture since BETA 153 due to UDT alignment changes
  • fixed: WM_UPDATEUISTATE sent to child HWND rather than the form HWND [ Krool, discord ]

BETA 165

  • fixed: compiler crash when editing code [ https://github.com//issues/1322 ]

BETA 166

  • added CoClass support [ https://github.com/twinbasic/lang-design/issues/52 ]
  • added attribute [CoClassCustomConstructor("procName")] to allow override of default CoCreateInstance behaviour for coclasses [ https://github.com/twinbasic/lang-design/issues/52#issuecomment-1265538725 ]
  • Global/App/Screen/Clipboard classes are now defined within the WinNativeForms package
  • WinNativeForms package types are now exposed via the VB qualifier [ https://github.com//issues/1326 ]
  • added check for OLEMISC_NOUIACTIVATE flag in ActiveXExtender.OnFocus event [ https://github.com//issues/1321 ]
  • fixed: ComboBox CB_SELCHANGE notification handling [ https://github.com//issues/1327 ]

BETA 167

  • fixed: Click event ordering in LBN_SELCHANGE (ListBox/FileListBox/DirListBox) [ https://github.com//issues/1327#issuecomment-1303666948 ]
  • fixed: some CoClass resolving was crashing due to a compilation ordering issue [ fafalone, discord ]

BETA 168

  • fixed: hover-info and F12/go-to-definition support for CoClass syntax [ fafalone, discord ]
  • added: support for attribute [ ArrayBoundsCheck(False) ] at procedure and component scope [ wqweto, discord ]

BETA 169

  • added: support for attribute [ FloatingPointErrorChecks(False) ] at procedure and component scope
  • fixed: tweaked RedrawWindow to use RDW_UPDATENOW in many instances [ fafalone, discord ]
  • fixed: ListBox.Selected(Index) was not working correctly for single selection lists
  • fixed: {ALL CONTROLS}.MousePointer/MouseIcon property updates are now reflected immediately [ https://github.com//issues/1329 ]
  • fixed: projects with CoClass declarations could sometimes crash the compiler [ fafalone, discord ]

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