This is my answer to those who bemoan the lack of rich GUI facilities in Windows Script Host (WSH).
Windows scripting comes down to a number of areas of application:
This list isn't exhaustive (there are DTS scripts, etc. as well) but it hits the highlights. The category I like to focus on is desktop scripts , which can encompass some sorts of administration scripts but when I say desktop script I mean something more general.
For me a desktop script is a script meant to be run by a user on his/her desktop computer much like any other locally-installed program such as an EXE like notepad.exe, etc. In general I mean a small desktop application written in script instead of a compiled programming language.
It seems that a lot of Windows script programmers come to the subject from an introduction to administrative scripting. Others probably approach it from the same angle because of the heavy slant toward admin scripts on Windows script oriented web sites and books.
As a result, they often get hung up on Windows Script Host (WSH) in both the cscript.exe and wscript.exe forms as if it is the Windows script host rather than merely a Windows script host.
When they have a script designed to interact with the user they quickly get dissatisfied with VBScript's MsgBox() and InputBox() and WSH's Popup(). This is probably especially true for those who have some background with classic VB (3/4/5/6).
Some go down the path of seeking 3rd party ActiveX components to achieve a richer UI. Others get led down the garden path of the topsy-turvy world of WSH scripts that automate instances of IE and try to manipulate these as a user interface by "puppet-stringing" the browser. While this has its place the result is often clunky, clumsy to develop with, terrible to maintain, and dare-I-say-it? Misguided.
There is a perfectly good alternative script host built into Windows. It is really part of IE in a sense because it makes heavy use of IE components, but since IE is part of Windows so is MSHTA.
Important parts of Windows are written as HTAs, for example the Add/Remove Programs Control Panel applet. You can use them for your applications too.
One of the slickest ways I've found to create impressive GUI VBScript applications is to make HTML Applications.
An HTML application is simply DHTML running under Internet Explorer 5.0 or
later, where the file is named with the extension .HTA instead of .HTM! That's
about all there is to it, aside from the special <HTA: Application> tag
The experienced WSHer will have to learn some HTML, but automating IE and pulling its strings has the same requirement anyway. The results can be quite gratifying.
No longer does scripting have to look like a refugee from the MS-DOS ghetto. You're no longer stuck in a world of limited popup dialogs.
Imagine event-driven programming like you've always wanted in a scripting language. There is even a control-name event binding mechanism like the one in VB forms!
My sample has a Sub window_onload() that takes the place of your VB Form_Load() event handler, it has Sub cmdChoose_onclick() in place of VB's cmdChoose_Click() for a command button. Sure, it's a little different - but not by much. Nothing like the mess you have in a WSH script.
Keep in mind that WSH actually offers very similar event binding. It's just a little messy to use cleanly to process GUI element events compared to doing this in an HTA. This may explain why it is so rarely used by most WSHers.
Ahh, there's the rub. Microsoft never bothered to release an IDE for HTA development.
There are 3rd party solutions out there, but I haven't found one I can recommend. I haven't worked with many of them. Most "VBScript editors" out there are WSH-oriented.
You can use MSE (Office's Script Editor) if you have a more recent version of Microsoft Office® installed. You even get color-coded code if you edit your script applications using MSE.EXE! The drawback here is that MSE won't edit an HTA file except as a text file. So you do your work on a copy called .HTM and when you're finished you copy it as .HTA for distribution or use. There may be a workaround for this but I haven't found one yet.
This gives you GUI form layout, code editing, and... ...by flipping from layout (Design) or code (Source) views to the run (Quick View) view you can even test it while you're working on it.
Visual InterDev® is another choice. I use this myself a lot, and it has all the advantages of MSE and then some. It does have the same "HTA is a text file" limitation as MSE, but there is a published workaround for InterDev:
To set up Visual InterDev 6.0 to recognize HTC or HTA files as HTML files, set the HTML editor as the default application to open files of type HTC/HTA. Use the following instructions to do this, once for each file type:
- Open a solution (Visual InterDev project) that contains an HTC or HTA file or open an HTC or HTA file into Miscellaneous Files of any default solution.
- In the Project Explorer window, right-click the HTC or HTA file and select Open With. The Project Explorer window appears at the top right of the workspace by default and shows a hierarchical view of your project files.
- In the list box on the Open With dialog box, select HTML Editor and then click the Set as default button.
- Visual InterDev will now syntax color script and tag declarations when you open HTC and HTA files in the future. HTC and HTA files open at the time of this change will need to be closed and re-opened to be viewed with the Visual InterDev HTML editor.
This can be found in Microsoft's Help and Support pages as article 200874. Maybe a similar approach will work in MSE as well?
There is always the trusty Notepad solution. Microsoft Script Debugger is another option worth looking into.
The sample code is here.
Unzip the file into a temporary folder, then run setup.hta to install it. To run an HTA you can simply double-click its icon in Explorer like any other application. Be sure to check out the brief readme.txt file.
Yes, you read it right. This sample archive contains two sample HTAs: one called setup.hta that is an installer for the other one vbsForm.hta which is a simple example of "forms" programming with HTAs. The installer puts a shortcut to vbsForm on your Start Menu.
After this you can try running the sample from the Start Menu. Then open vbsForm.hta with MSE, Visual InterDev, Notepad, or your favorite text editor to see how it is done.
vbsForm has VBScript, the FSO for file I/O, a standard Windows file open dialog, radio buttons, command buttons, text boxes, labels. And you can go way beyond this with little effort.
Yes, this article is long on hype and short on technology. I may write more about HTA development at some point because there is a dearth of good information available on the Web.
You can check out Microsoft's MSDN Library though for a few articles on HTAs as well as a basic reference on the properties of the <HTA: Application> tag itself. This tag gives the developer a lot of control over the HTA window, a way to associate an icon with your HTA, and some control over the application itself through properties like singleInstance and showInTaskBar.
Information on lpktool is worth looking into as well. HTAs use the same ActiveX licensing technology that regular IE HTML pages do.
Don't miss the information on the HTA security model, especially as it applies to frames and iframes.
December 2001
