However, the copy-and-paste approach is prone to error. You can easily miss a line or pick up an extra line when selecting the text to copy. This approach also leads to scripts that are difficult to debug, edit, and maintain. If you need to change the code that carries out the action, you must change each pasted instance. Storing the action in a subroutine or function, then calling it as needed makes the code easier to debug, edit, and maintain.
Procedures can also help you be more flexible about storing data. In previous columns, I've shown you how variables work: You define the variables you plan to use at the beginning of the script (at least, that's how I recommend doing it to simplify debugging), then assign values to those variables. But these variables are, well, variable. Their values can change in the course of a script's execution. Sometimes you want their values to change, but other times you want the variable's value to be specific to a portion of the script and unaffected by anything else that happens in the script. With procedures, you can have "static" variable values. Variables defined and manipulated solely within the context of a procedure are called local variables. The variables available to an entire script are called global variables. Both local and global variables are useful; they're just used for different purposes.
Creating the Script One Piece at a Time
With procedures, you can construct a script by creating smaller, less daunting pieces of code, then assembling those pieces into a script. To construct CheckNCreateUser.vbs, I created a module of code that collects input, a subroutine that makes sure a user account doesn't exist for a specified username, and a subroutine that creates a user account. I then assembled those pieces into a script.
Collecting the Input
Rather than collecting input from the machine on which the script will run, the input module collects input from the administrator launching CheckNCreateUser.vbs. To launch CheckNCreateUser.vbs, the administrator must supply two arguments: the name of the user for which to create the account and the name of the domain in which to create that account. If the administrator doesn't provide this information, the module prompts the person to do so. (Although you could hard-code the username and domain name in the module, you'd have to edit the script each time an administrator wants to search for a different user account, which would be a lot of work and possibly introduce errors.) After the administrator provides the necessary input, the module retrieves the input and stores it in global variables.
Callout C in Listing 1 highlights the input module. The module uses WSH's WScript.Arguments property to retrieve the input as a collection of arguments stored in the WshArguments object. In the WshArguments object, an argument is any combination of characters separated from the next argument by any number of spaces. If you want to use an argument that includes a space, you must enclose it in double quotes. Therefore, Peggy, "french fries", 123456, and //??.. are all valid arguments to store in WshArguments.
WSH numbers the arguments in the order that the administrator inputs them, starting with 0. Therefore, the first argument in the collection is 0, the second argument is 1, and so on. To retrieve a particular argument, you specify WScript.Arguments(x), where x is the number of the argument you want to retrieve. So, for example, if you want to retrieve the fourth argument, you specify WScript.Arguments(3). Even when the collection contains only one argument, you still must specify that you want to retrieve the first argument, WScript.Arguments(0).
You can use the WshArguments object's Count method to count the number of arguments in a collection. In the case of CheckNCreateUser.vbs, the collection must contain two arguments: WScript.Arguments(0), which represents the username, and WScript.Arguments(1), which represents the domain name. If the collection contains fewer than two arguments, the module displays the message Please provide a username and domain name in that order, then quits. If the collection contains two arguments, the module assigns WScript.Arguments(0) to the global variable called sUserName and WScript.Arguments(1) to the global variable called sDomainName.
In the code at callout C, notice that I didn't include any code that makes the script accept arguments. VBScript always accepts arguments; it just won't do anything with them unless you tell it to.
Prev. page
1
[2]
3
next page 
