WinBatch is a handy scripting language for Windows

We Visual Basic programmers run the risk of complacently believing that network management and user support have little to do with us. After all, shouldn’t we be far more concerned with program design and construction techniques—with components and objects, coupling and cohesion?

Yes indeed. But what good is programming expertise when your program crashes because it can’t find a file or because the user isn’t logged into the proper network drive?

Say you’re developing a client/server app. During the initial stages of development, the server and database names are likely to be hard-coded somewhere. This works fine until user testing begins and someone introduces a second data source. So you change the hard-coded filename whenever you generate a user test version. That works, too (for a while), but it’s also likely to introduce errors and troubleshooting confusion.

“Maybe an INI file will help,” you say. So you take a little more time out of your project to round up the parameter-handling code and redirect it to the INI file. But by now the user-tester population is growing, and some workstations contain outdated or absent DLLs. You’re faced with the prospect of either configuring 10 workstations manually or hacking out a Visual Basic program that handles these details. But experience has shown that if you write such a program, you’ll be tinkering with it for the next two weeks, and that’s the last thing you need at this stage in the game.

All of a sudden, and without realizing it, you’ve stopped working on your application. Now you’re all wrapped up in the problem of maintaining it in a fluid environment. None of these efforts improve the user interface or streamline your code. What you really need is a BAT file—something that can set the stage for your application without requiring you to burn precious time plowing through the API docs and pasting function declarations to a form.

WinBatch to the Rescue

What you need is WinBatch, a batch script language, interpreter, and optional compiler from Wilson WindowWare. Stick a WinBatch script behind your icon and let it take care of the grunt work before it fires up your application. With WinBatch, you can write the equivalent of BAT files for the Windows environment.

The WinBatch package includes a thin user’s guide and a larger reference manual that documents the batch commands. Both volumes do a good job of providing both a high-level overview and low-level details about how to utilize WinBatch effectively.

After a brief introduction to WinBatch and a few examples, the user’s guide documents network extenders for NetWare 3.x and 4.x, Windows 3.1, and Windows For Workgroups. [ed. note: New extenders handle networking for Windows 95, 98, NT 3.51, NT 4.0, and all versions of Windows 2000.] The extenders enable such network functions as attaching, logging in, and drive mapping, the guide also covers WinBatch’s dialog editor and optional compiler.

The compiler turns batch scripts into stand-alone executable files that can run on any machine, even if WinBatch isn’t installed. This makes it easy to distribute WinBatch programs.

The WIL reference manual is focused and clear. It contains an excellent tutorial, and it’s full of examples. The manual also includes frequent explanations for novices and nonprogrammers—many people who use batch languages extensively don’t program as their main activity.

Following the tutorial is a reference section that lists WIL’s 250-plus [Wilson WindowWare note: in year 2,000 over 1,000 including core language functions and functions in extenders.] functions, grouping them by functional category. Many functions appear in more than one category, which makes it easier to find the one you need. The functional reference section follows with a description of each function and an example for each. The manual also has a Quick Function Reference—an alphabetical list of the functions and their syntax. It’s an excellent book that quickly brings you up to speed on this tool.

Syntactic Sugar

WIL’s syntax consists of function names followed by arguments in parentheses. This should be familiar to Visual Basic and C programmers. Flow control includes If/EndIf, Else, While, Switch, GoSub, and GoTo. A batch file can call another batch files with Call, and Return gives control back t the first one. These functions provide a distinct improvement over DOS batch-file flow control.

You write WinBatch script files with Notepad or any ASCII editor, [ed. note: WinBatch now includes an editor called WinBatch Studio.] If you save the script with a WBT extension, you can execute it directly—the install program associates the WBT extension with the WinBatch Processor.

The tutorial leads you through the creation of a batch file that runs Solitaire for a user-defined time period. The tutorial also demonstrates the flexibility of commands, such as the Run command, which starts Windows and DOS programs (including DOS batch files). WinBatch provides several versions of the command. Run uses command- line arguments to start a program in a normal window, then immediately returns control to the batch files. The RunZoom variation fires up the program in maximized mode, RunIcon runs it iconized, and RunHide runs it hidden. Other variations include RunWait, RunZoomWait, RunIconWait, and RunHideWait. With these commands, the WinBatch file continues only after you exit the spawned program. There’s even a RunExit variation that quits Windows, runs a DOS program, and restarts Windows when the DOS program is done.

Having so many versions of the same command may seem unnecessary, but the variety makes it easy to choose a command quickly and slap it into your batch script with minimal custom coding.

If you want, you can always use the generic RunShell command and pass it parameters to accomplish the specific task you need. The tutorial also introduces you to functions that allow your script to monitor the activity of other Windows apps. AppExist, for instance, tells if an application is running. AppWaitClose puts you on hold until the user closes the specified application. WinExist locates open windows using either a full or partial title.

WinExeName tells you which EXE created any Window. WinGetActive and WinActivate identify and set the current window. You can maximize, show, iconize, or hide a window, as well as change its title, size and position. You can even use MsgGetText to pluck the text from any standard Windows message box.

Interacting with Users

WinBatch gives you many ways to interact with the user. Your script can display message and progress boxes. You can use the AskLine command to get a line of information. AskPassword hides what is being typed, and AskYesNo gets the user’s answer.

It’s often convenient to display a list of items and have the user pick one or several. WinBatch takes care of this with AskItemList and AskFileText, which display a list of items provided by your script or a text file. You can also put up a File Open dialog box and retrieve the user’s selection.

Another set of WinBatch commands deals with inter program communication. You can use them to store data in the Clipboard or fetch it back. In addition, your batch file is a DDE client, so it can converse with any DDE server. This means that your Visual Basic program can call a WinBatch file to perform a task you'd rather not bother coding. The WinBatch program can send the results via DDE and the users will never be the wiser!

WinBatch has a complete set of commands for managing files, both externally (Exist, Copy, Delete, Touch) and internally (Open, Read, Write, and Close, for both text and binary files). Specialized functions read and write INI files.

Rounding out the package are all the string, math, and time functions you’ll ever need. You can load DLLs, open and close OLE automation objects, and manipulate the registration database, Change the environment variables if you like. You can Play WAV files, log into servers, and map network volumes.

My only complaint involves the Cancel button and Ask… boxes: it transfers control to the Cancel label if one exists in the script. If there’s no such label available, Cancel terminates the script. Because the batch file can have only one such label, this somewhat hinders your ability to question the user at several different points in the script. However, both called and calling batch files can have a Cancel label—you can regain some flexibility by separating various blocks of commands into individual files.

Sending It Off

One of my first Visual Basic programs was a utility that installed networked applications on the fly, logged into a NetWare server festooned with CD-ROMs, mapped local drive letters to the volumes, and ran the CD-ROM apps. Then it waited in the background and unmapped volumes as the applications closed. After the last one closed, the utility detached the server and bowed out. I was happy with the utility, but if I had written it as a WinBatch script, I could have done it much more quickly.

We have gotten very clever over the years in building powerful, flexible, DOS batch scripts. MyApp was designed to replace a script written with another Windows batch product that didn’t quite meet the users” needs. WinBatch makes the grade. As Windows continues to grow away from its DOS roots, WinBatch could become a natural Windows-based successor to its more rudimentary predecessor. I wonder if the world is ready for AUTOEXEC.WBT.

WinBatch Pros

With over 250 [now over 1,000] commands and functions, WinBatch brings the convenience and power of batch language programming to Windows. A lot of API functions are included.

WinBatch Cons

You’ll probably end up relaxing your steadfast inhibitions against using GOTO. You may also wish the Cancel buttons on the built-in dialog boxes were more flexible.

Tony Shaftel codes Visual Basic client/server apps and does daily obeisance in the direction of the Pacific Northwest. Whether this means Redmond or the birthplace of Steve McConnell’s Code Complete has yet to be determined.