Mr. Script
An HTA Reality Check
Simplify your administrative life with HTAs.
- By Chris Brooke
- 02/01/2005
Last month we learned about the exciting world of HTML Applications, or HTAs. This month, we're going to learn more about some useful features inherent to HTAs that can help simplify your administrative life, as well as expound upon features we've already become familiar with.
Before departing on this whirlwind tour into user interface-based scripting, however, I must present one caveat: HTAs are not a panacea for all scripting ills. Rather, they're simply another tool you should keep in your scripting toolkit for use as appropriate. There are some limitations of which to be aware.
The Restrictions
First, you cannot use .WSF scripts inside HTAs. WSF scripts are XML, HTAs are HTML. This isn't so bad, as these things go, because you can still do (pretty much) anything in "standard" VBScript that you can do in a .WSF script. You lose the enhanced handling of arguments that WSFs provide, but you gain the ability to enter arguments in even more cool ways—like selecting them from lists!
Another limitation of HTAs is that the script functionality must be organized into Subs (which stands for "sub-program" or "subroutine," depending on who you ask). This can work to your benefit, however, because it forces you to adopt a more structured script writing style. Those who have been following this column for a while will remember that we discussed Subs and Functions some time ago. By breaking code down into discreet blocks of functionality, you build scripts that are more flexible and easier to understand when debugging.
But, whereas Subs must be explicitly called via the code of a "regular" script, in HTAs the Subs are event-driven. This means they just sit there and do nothing (with the exception of the Window_Onload Sub, which runs automatically when the HTA is loaded) until someone clicks a button, changes the selected item in a list or ticks a checkbox or radio button. This may seem a bit confusing at first, but you'll be surprised how quickly you get used to it.
 |
| Figure 1. HTAs allow you to verify each task completes properly before moving to the next. In this case, you can see that the database is created, then a table. Finally, data is added to the table. |
So, What Can They Do?
Now that you no longer expect your HTAs to cure the common cold, let's take a look at what they do well. One thing they do very well is consolidate multiple tasks into a simple interface. To demonstrate, we're going to use the multi-step database creation script we created last October and set up each step as an individual task in the HTA.
Database Tasks
<>
ID="objDBCreate"
APPLICATIONNAME="DBCreate"
SCROLL="no"
SINGLEINSTANCE="yes"
WINDOWSTATE="normal"
>
Visual Scripting—What a Concept!
In addition to combining what were originally three separate scripts, we've also given the administrator control over Database and Table names—they're no longer hardwired in the script. Note how systematic it is: You can't click the "Add Table" button until you've created a database.
Likewise, you can't click "Add Data" until you've created a table. The
actual data that is written to the table is still hardwired in the script, but we'll add the capability to display and change formatted data next month (along with a few other surprises). Until then, have fun experimenting with HTAs.
More Information
Subs and Functions:
"Get Yourself Organized"
Functions not only help you organize your scripts into subroutines, they also let you choose between going global or staying local.
About the Author
Chris Brooke, MCSE, is a contributing editor for Redmond magazine and director of enterprise technology for ComponentSource. He specializes in development, integration services and network/Internet administration. Send questions or your favorite scripts to [email protected].