twinBASIC Update: September 11, 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:

• 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

New Form Controls Added

The following form controls were added this week:

• TreeView common control
• DriveListBox
• DirListBox
• FileListBox

Around the Web

Q&A on the twinBASIC Discord Server

Over on the twinBASIC Discord server, user kismertwise asked the following questions:

I have some questions about how ready for prime-time twinBASIC is:
1) Is there a hard limit on the number of variable, constant, label, routine, class and module names? (The current VBA limit is 32K)
2) Is there a 2GB memory limit on 32-bit twinBASIC apps?
3) If (2) is true, how easy is it to make a Large Address Aware twinBASIC app?
4) If I tried to move our VB6 code to 32-bit twinBASIC (about 200,000 lines), is there some reasonable chance of that working?
5) Related to (4), how backwards compatible is twinBASIC?
6) Lastly, is there a twinBASIC manual?

Wayne Phillips provided the following answers:

1)  no, there are no artificial limits imposed in tB.
2)  you can turn on Large-Address-Aware support (LAA) in the project settings in an EXE project.  For a DLL project though, the LAA is managed by the host EXE, i.e. MSACCESS.EXE in this case, and so it will have no affect.
3)  Making an LAA application (EXE) in tB is easy, and provided any DLLs/OCXs you reference are designed to work with LAA, all will be fine.  Note that if you do any pointer manipulation (VarPtr, ObjPtr, StrPtr), then you need to be aware that tB doesn't yet offer an unsigned datatype, so there is a small risk of hitting overflow errors in your pointer manipulation code if data overlaps the 2Gb boundary.
4)  Yes, there's a reasonable chance.  I know of several people now using tB in production on very significant sized codebases.  I personally can't fully endorse using it in production yet, and won't until we reach a stable v1 release, but of course I understand that it would be suitable in some situations.
5)  As mentioned, the language support is currently much more evolved than the UI controls support.  I would guess you're probably using mostly non-UI features in your VB6 DLL project, so the current situation is likely to be suitable.
6)  Not yet, sorry

Modifying the WinNativeForms Package

Wayne posted the following note in the Discord server:

Just in case anyone wants to play around with making changes to the UI controls implementations (either just for experimentation, or to make suggestions for improvements)...

The sources haven't been published officially, but they are available in each ZIP release.   If you navigate to the 'packages' folder from the root twinBASIC IDE folder, you'll see a package named '{F50B82D0-DCAB-43FE-9631-11959D4A4728}', this is the WinNativeForms package.  Inside that folder you'll find a package.twinproj file.

You can open the package.twinproj file in twinBASIC like any ordinary twinproj file....  and modify it, and save it.   When you next open (or create) a project file that contains a reference to WinNativeForms, your changes will automatically be merged into the project.

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 109

• fixed: HISTORY panel sometimes contained multiple entries for the same Form design
• fixed: some FPU codegen issues [ https://github.com//issues/1144 ]
• fixed: return-value optimization with ANSI-UDTs issue [ https://github.com//issues/1143 ]
• fixed: members marked as non-browsable are now shown in intellisense lists [ e.g. MSCOMCTL.ListView.ListItems ]
• fixed: sporadic "[LINKER] compilation (codegen) error detected in '.'" errors in the debug console [ fafalone, discord ]

BETA 110

• added: TreeView common control (Image and OLE properties not yet implemented)

BETA 111

• fixed: bug in TreeView implementation (missing DLL Alias) [ https://github.com//issues/1146 ]

BETA 112

• added: DriveListBox
• fixed: bug in TreeView.Add implementation not allowing index/key to be passed in the Relative argument [ feldharke, discord ]

BETA 113

• added: DirListBox
• fixed: DriveListBox missing volume / share information [ fafalone, discord ]

BETA 114

• fixed: use of GetVolumeInformationW API in DriveListBox [ fafalone, discord ]
• fixed: DirListBox support on Win64 target

BETA 115

• fixed: further fixes for DirListBox and DriveListBox [ fafalone, discord ]

BETA 116

• fixed: DirListBox.Path property-get implementation [ fafalone, discord ]
• added: DirListBox.PathSelected property
• fixed: DirListBox and DriveListBox now cache their StdPicture images once only in a shared cache between instances
• fixed: duplicate 'datatype has not been explicitly declared' errors for ByVal parameters [ https://github.com/ ]

BETA 117

• fixed: implemented HandleEraseBackground for ComboBox LIST [ https://github.com/ ]

BETA 118

fixed: invalid removal of call parenthesis in parser in some instances [ https://github.com/ ]

BETA 119

• added: FileListBox