Pseudo-Command Line Args in twinBASIC

UPDATE [2021-05-31]: This feature is now natively supported in twinBASIC.

Today I decided to try converting my Decompose script from VBScript to twinBASIC.  Unfortunately, I didn't get very far before I realized that I would need a way to pass command line arguments to the script to make it work.

I checked the current code samples and searched the twinBASIC GitHub issues page, but I could find no reference to an approved way to handle command line arguments.

Opening a feature request

The first step was to open a feature request for command line argument support.  Depending on when you are reading this article, that link will probably have the official solution.

In the meantime, I didn't want to wait around.  So I forged ahead with a workaround.

The Workaround: Environment Variables

One thing that twinBASIC does have is support for the VBA Environ() function.  

This turned out to be a pretty neat and tidy workaround, actually.  Here's the simple test code adapted from the Sample 1 Hello World project:

If I press the Build button in VS Code, the message box looks like this:

That's because the environment variable TwitterHandle does not exist within the context of VS Code.  However, the build button also generates a twinBASIC .exe file.  We can run the .exe file from the command prompt after first setting the TwitterHandle environment variable:

We can also combine the setting of the environment variable with the call to the console application in a single line using the && operator of the cmd console:

...\Build> set TwitterHandle=WaynePhillipsEA && HelloWorldProject_win32.exe

Here is the same thing in Powershell rather than the cmd console:

PS ...\Build> $env:TwitterHandle="NoLongerSet"; .\HelloWorldProject_win32.exe

Debugging from VS Code

The only remaining problem is that we still get a "Hello, @" message when pressing the Build button from within VS Code.  The reason for that behavior is that VS Code is running in a different environment than the cmd and Powershell consoles.  

There are a couple of things we can do about that.  The overkill approach would be to use an admin cmd or Powershell window to set global environment variables.  But that's like bringing a boulder to a rock-paper-scissors tournament: it will solve our current problem, but could break a bunch of other stuff (especially if you decide to do something unintentionally disastrous like naming one of your pseudo-command line arguments path).

A far better approach would be to simply launch VS Code from within a cmd or Powershell console.  All you have to do is set the environment variables to whatever values you want BEFORE you launch VS Code from that console.  

VS Code–like all processes–caches the environment variables when it starts.  If you need to change the environment variables while debugging, you will need to set the new values in the console window, then close and reopen VS Code.  Remember to open it from within the same console window where you set the environment variables.

Powershell example

Cmd console example

Image by OpenClipart-Vectors from Pixabay