| TABLE 1: Windows Script File Grammar | ||
| WS File Element | <element attribute="value"> Syntax | Description |
| <job> | <job
[id="JobID"]> . . . </job> | The <job> element lets you define several jobs in one WS file. You set the id attribute to a unique string identifier for each defined job in the file. You subsequently use the job id in conjunction with the WSH //job:id command-line option to specify which job to run in a multiple-job WS file. By default, WSH runs the first job in a multiple-job file when you don't specify a command-line //job:id at runtime. WS files that contain several jobs must also include the <package> element. (The <job> element is one of two mandatory elements that you need to convert WSH 1.0 scripts to WSH 2.0 WS files.) |
| <?job ?> | <?job error="flag" debug="flag" ?> | The <?job ?> element provides error-handling attributes. The error and debug attributes are Boolean values that you can set to true or false, 1 or 0, or yes or no. False is the default value for both attributes. When you use the <?job ?> element, you must define it immediately following the <job> element. |
| <object> | <object
id="objID" [classid="clsid:GUID" | progid="ProgID"] /> | The <object> element provides another way to create objects. The id attribute is the name that you use to reference the object in the script. You use the classid or progid attribute to specify the globally unique ID (GUID) or the programmatic identifier (ProgID) for the object you're creating. You need to specify one of these two optional attributes. (You can use the <object> element as a replacement for the WSH or VBScript CreateObject and GetObject functions.) |
| <package> | <package>
. . . </package> | You must use the <package> element in WS files that contain multiple-job definitions. You place all job definitions between the <package> and </package> tags. The <package> element is optional in WS files that contain only one job. |
| <reference> | <reference
[object="ProgID" | guid="typelibGUID"] [version="version"] /> | The <reference> element provides access to constants defined in objects that are external to the script engine. You must provide an appropriate value for the object or GUID attribute. The version attribute refers to the major and minor version number of the object you're referencing. |
| <resource> | <resource
id="resourceID"> . . . </resource> | You use the <resource> element to isolate string or numeric data that you don't hard-code into a script. For example, you typically use resource elements to maintain strings that you might localize into other languages. To get the resource value, call the getResource method and pass it the resource ID you want to use. |
| <script> | <script
language="language" [src="strFileURL"]> . . . </script> | You use the <script> element in conjunction with the language attribute to govern which script engine WS will use to interpret the script block's enclosed code. The <script> element also provides the src attribute that you can use to include external files in the active script. (The <script> element is the second of two mandatory elements that you need to convert WSH 1.0 scripts to WSH 2.0 WS files.) |
| Note: You must lowercase XML element and attribute names when you enable XML validation. You also need to enclose attribute values in double quotes. XML 1.0 specifies that you must close elements that don't contain content (e.g., <object>, <reference>, and sometimes <script>) with a single slash (/). The syntax is <element attribute(s) [attribute(s)] />. | ||