twinBASIC Update: November 14, 2021

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.

Highlights

Partial Inheritance Support

twinBASIC now provides partial inheritance support in the form of the Implements ... Via ... construct as discussed in the GitHub issue titled, "Inheritance?"  Documentation is not yet available.  For usage, refer to the above GitHub issue and the code in twinBASIC Sample 6.

To load Sample 6:

• Press [F1] in VS Code
• Search "twinBASIC: Create new project"
• Select the "twinBASIC: Create new project" command
• Choose "Sample 6. CustomControls"

New Custom Controls Features

The following features were added in twinBASIC version 0.12.1:

• Create forms programmatically
• Proper event support (including EXE creation support)
• Added ControlContext.IsDesignMode property
• Button to switch between form and design views

To play with some of these new features, I highly recommend you follow the instructions above to download the twinBASIC CustomControls code sample (Sample 6).

Around the Web

Custom Controls Available in Alpha Preview Without License

Announcement from Wayne:

As of v0.12.1, the custom controls feature is now unlocked for all users (not needing a licence key).  It is still an ALPHA feature, so be aware that there certainly will be bugs at this stage!

Sample 6 (Custom Controls) has been updated to offer a simple walkthrough of the sample forms.  As you will discover, real forms can now be created along with real event bindings.

You can also build an EXE from your project, though be aware that the built size of the executable is currently more bloated than it will be once CustomControls support has been more refined. Sample 6, with 10 forms currently compiles to ~2MB in size.   The Sample 6 EXE has been tested back to Windows XP without issue.

Further documentation to follow.    Have fun!

To add a form to your twinBASIC project, use the "Add Component" button in the TWINBASIC VS Code toolbar, then choose "Form" as your component type:

Set a Shortcut Key to Run twinBASIC Code

Tip from Wayne:

In VS Code, press F1, type 'Open Keyboard Shortcuts (JSON)'.  In the JSON file that opens, create an entry like this:

// Place your key bindings in this file to override the defaults
[
    {
        "key": "f4",
        "command": "twinbasic.debuggerExecute",
        "args": "Main",
        "when": "twinBasicIsEnabled == true"
    }
]

( reference:  https://code.visualstudio.com/docs/getstarted/keybindings#_accepted-keys )  

Save the file, and the keyboard shortcut should work.

Following Wayne's example, pressing the [F4] key when the twinBASIC extension is enabled will result in VSCode trying to execute the Main subroutine via the debugger.

I assume you can run something other than Main, though you would probably want to pick the name of a method that will be in every one of your tB projects.  

Tip to Avoid Possible Frustration

According to Wayne,

VS Code keeps an internal database of project state, e.g. what code editors are open so that it can restore them when you next open the project.  Unfortunately, this can sometimes cause problems, and prevent you from being able to open a tB project.

The easiest workaround is to simply rename your .code-workspace and .twinproj files, and then VS Code will not try to restore the project state when you open it, and all should be back to normal.

Here's what your twinBASIC project will look like when you open it in VS Code if you get bitten by this bug:

Wayne's World! Party Time! Excellent!

If you have been following along with the GUI preview, you will no doubt have noticed that several of the control samples are prefixed with Mr. Phillips's first name, such as WaynesButton, WaynesTextbox, etc.

Over on GitHub, one commenter was concerned that these might end up being the official names for these controls, "Ok, I know that this is your name, but it can be shorter, simpler, easier to read and even more compatible to use the original VB6 control names, 'Frame', 'Button', 'Form', etc"

Wayne assures us that this is not the case:

Naturally, these aren't the final control names :)   The current set of controls in Sample 6 are just provisional.  They should be considered examples of how to create CustomControls, and certainly not considered as finished controls.  The final controls will be simpler and more similar in design to normal VB6 controls.

That all makes sense, but I still have one request.  If someday twinBASIC supports some type of GIS-based mapping control, please, please, please bring back the Alpha Preview naming style and call it WaynesWorld.

I'll see myself out now.

Changelog

Here are the updates from the past week.  You can also find this information by installing the twinBASIC VS Code extension and clicking on the Changelog tab of the extension page:

[v0.12.120, 11th November 2021]

• fixed: regreesion; 'Dock' property was not showing correctly in the form designer property sheet since last update

[v0.12.117, 10th November 2021]

• fixed: Environ() function would crash in a compiled EXE/DLL if the function was called from within the IDE environment prior to building [ https://github.com/WaynePhillipsEA/twinbasic/issues/485 ]
• improved: Custom controls building now less bloated (e.g. Sample6 compiles to 733KB now rather than 2.2MB)

[v0.12.1, 9th November 2021]

• removed: LicenceKey requirement for CustomControls. Now open to all for testing the current alpha.
• added: support for creating instances of forms programmatically, and proper event binding, including EXE creation support
• added: Serialize(Boolean) attribute so that you can control whether a field/property is auto-serializable independently of the accessibility of the field/property. Public defaults to True, Private defaults to False.
• added: support for generic class field events of OnPropertyGet/OnPropertyLet/OnPropertySet to capture when the auto-property is accessed from outside of your class
• added: support for Implements-Via for partial inheritance support, only for twinBASIC defined interfaces for now [ https://github.com/WaynePhillipsEA/twinbasic/issues/73 ]
• improved: CustomControls now use the Implements-Via method for inheriting base control fields, see Sample 6
• fixed: WithEvents fields would not expand in the debugger Variables list, showing only '{no members}' when expanded
• added: WaynesTimer sample control
• added: ControlContext.IsDesignMode property
• removed: WaynesDateTime, and changed Example_DateTimeControl to use a standard Label and Timer instead, renamed to HelloWorld.tbform
• fixed: big memory leak in editing source files since recent update
• fixed: runtime memory leak involving fixed-length arrays
• fixed: bugs involving non-simple field initializers, should now be more stable
• added: a 'switch between form and design' VS Code extension command, and added a button associated with it to the top right of the editor tabs