DOWNLOAD THE CODE:
Download the Code 41503.zip

Error Events
WSH automatically traps and responds to error events in scripts. For example, suppose that you write a four-line script that generates an error on line three. When the script encounters the error in the third line, WSH raises an error event. WSH then automatically traps the error event, terminates the script, and writes the error details to the standard output, which is a dialog box or the command prompt, depending on whether you ran the script from wscript.exe or cscript.exe, respectively.

You can tell WSH not to respond to any error events by including the On Error Resume Next statement in your script. When you use this statement and WSH encounters an error, WSH continues to execute lines as well as it can. In other words, WSH doesn't stop the script's execution. Typically, you place the On Error Resume Next statement at the beginning of a script, although you can place it anywhere.

When you use On Error Resume Next, you need to use an alternative method to check for errors in your code. The article "Scripting Solutions with WSH and COM: Trapping and Handling Errors in Your Scripts," May 2001, http://www.winnetmag.com/windowsscripting, InstantDoc ID 20500, describes several error-checking methods you can use in WSH scripts. One of these methods uses the CheckError subprocedure to trap and handle runtime errors. CheckError takes advantage of VBScript's Err object, which returns information about runtime errors. This intrinsic object has global scope, which means you don't need to create an instance of the object in your code. Because you can set the Err object's properties, you can raise errors in your scripts that either WSH or an error handler (such as CheckError) can automatically handle.

The script SimpleRaiseError.vbs, which Listing 2 shows, demonstrates how to use the Err object. To raise your own errors, you must use a hexadecimal value higher than 80040000. So, in SimpleRaiseError.vbs, I set the vbObjectError constant to a hex value of 80040000 and later increment this value by 1.

Next, I use the Err object's Clear method to make sure no previous errors exist. Clearing the error fields before you raise an error is good practice; otherwise, the Err object might include data left over from a previous error. When WSH encounters the Clear method or the On Error Resume Next statement, WSH resets the Err object's properties to 0 (i.e., an empty string).

After clearing the error fields, I use the Err object's Raise method with three out of five possible parameters. The first parameter is the error number that I want to use, which is 80040001 in this case. The second parameter is a string that specifies the source of the object or script that caused the error. The third parameter is a string that provides a simple description of the error. The two parameters that I didn't include are the helpfile and helpcontext parameters, which provide pointers to a Help file and a topic in a Help file, respectively. You're unlikely to need to use these two parameters in a script. Finally, I end the script by using the MsgBox function to display the information that the Err object captures.

For background information about error handling, go to the TechNet Script Center (http://www.microsoft.com/technet/scriptcenter/default.asp). In the directory on the left, navigate to Scripting Guides, Windows 2000 Scripting Guide, Scripting Concepts and Technologies for System Administration, VBScript Primer, VBScript Reference, Error Handling.

WSC Events
You can create custom controls that support automation—and you don't have to be a programmer or have a program-development tool to do so. As an alternative to programming, you can create custom automation-supporting controls and register them for use. These controls can have methods, properties, and events, just like ActiveX controls. Such controls are known as WSCs.

I don't cover WSCs any further in this article. I've already done so in a previous four-part series:

  • "Scripting Solutions with WSH and COM: Using WSC to Build a Progress Bar Dialog Box, Part 1," September 2000, http://www.winnetmag.com/windowsscripting, InstantDoc ID 9802
  • "Scripting Solutions with WSH and COM: Using WSC to Build a Progress Bar Dialog Box, Part 2," October 2000, InstantDoc ID 15641
  • "Scripting Solutions with WSH and COM: Using WSC to Build a Progress Bar Dialog Box, Part 3," January 2001, InstantDoc ID 16297
  • "Scripting Solutions with WSH and COM: Using WSC to Build a Progress Bar Dialog Box, Part 4," February 2001, InstantDoc ID 16406

You can also find out more about WSC in the Microsoft Developer Network (MSDN) Library (http://msdn.microsoft.com/library). In the directory on the left, navigate to Web Development, Scripting, Documentation, Windows Script Technologies, Windows Script Components.

An Eventful Beginning
I hope that this article has given you a good introduction to events in WSH. In a follow-up article, I'll show you how to create more advanced event-driven scripts, including scripts that trap error events for remote scripts and scripts that use WMI for synchronous and asynchronous event monitoring.

End of Article

Prev. page     1 [2]     next page -->



You must log on before posting a comment.

If you don't have a username & password, please register now.

 
 

ADS BY GOOGLE