Using a Script Component in an Application
After creating a Windows Script Component, you can use it as you would any COM component, by calling it from a host application such as Microsoft Visual Basic, C++, Microsoft Internet Explorer, or other applications.
Creating an Instance of the Script Component
There are a variety of options for creating an instance of the script component, depending on the host application, the type of script component you are using, and where the script component is deployed. The primary difference, however, is whether you want to create an instance of the script component locally (on the same computer as the application) or remotely (on another computer).
Note
Script components written for DHTML Behaviors are instantiated differently than traditional COM objects. For details, see Using DHTML Behaviors on the Microsoft Site Builder Network (SBN) Web site.
In either case, there are a few points to bear in mind. If you create an instance of the script component and change the .wsc file while using that instance, your instance of the component is not updated. To update it, create a new instance of the script component.
The exact properties and methods you can use are defined by the <public> element and by scripts in the script component file. If you are working in an environment that supports statement completion, such as Visual Basic, you can see a script component's properties and methods if you generate and use a type library. For details, see Creating a Script Component Type Library.
If your attempt to create an instance of the script component fails, a likely cause is a syntax or run-time error in the script component file. A parsing error in any XML element (including the <registration> element) can cause the instantiation to fail. While you are developing your script component file, set error checking options in the <?component?> processing instruction as described in Checking For Errors in Script Component Files.
Tip
To make it easier for the host application to know about the COM interfaces exposed by a script component, the script component run-time can generate a type library, which contains information about the properties, methods, and events available in the script component. For details, see Creating a Script Component Type Library.
Creating Local Instances of Script Components
If the script component is installed on the same computer as the host application, you can register the script component as its own component as described in Registering a Script Component. You can then use the host application's normal means for creating an object instance, such as the CreateObject function. For example, to create an instance of the script component that was registered with the program ID Component.MyComponent in Visual Basic, use a statement such as this:
Set oComponent = CreateObject("Component.MyComponent")
Note
If your host application is Visual Basic and you want to handle events fired by the script component, you must bind the object early with a Dim statement that includes the WithEvents keyword, such as the following:
Dim WithEvents scMyComponent As MyComponentPrivate Sub Command1_Click() Set scMyComponent=CreateObject("MyComponent")End Sub
Note
For details, see Handling Script Component Events in the Host Application. This is not necessary if you do not intend to write handlers for script component events.
On a Web page, you can use the <OBJECT> tag to create an instance of the script component. You must know the class ID of the script component and include it in the <OBJECT> tag, as in the following example:
<OBJECT
ID="oComponent"
CLASSID="clsid:855c8606-49ba-11d2-a428-00c04f8ec80b">
</OBJECT>
If the script component is not registered on the local computer, you can use the script component moniker to create an instance of it. The moniker is supported in functions such as GetObject. The script component run-time, Scrobj.dll, must be registered on the local computer.
Note
The GetObject function is not supported for script components in Microsoft Internet Explorer for security reasons.
For example, the following illustrates how to call the Visual Basic GetObject function to create an instance of an unregistered script component:
Set oComponent = GetObject("script:c:\COM\MyComponent.wsc")
If the .wsc file referenced by the moniker contains more than one script component, you can specify the script component to instantiate by adding its name to the file name with a hash mark (#) as a delimiter. The following creates an instance of the script component whose ID is "math" contained in the file MyComponent.wsc:
Set oComponent = GetObject("script:c:\COM\MyComponent.wsc#math")
Using a URL moniker allows you to create an instance of a script component that resides on another computer, such as a Web server. Use a complete URL (with HTTP protocol) as the location for the script component, as in the following example:
Set oComponent = GetObject("script:http://myserver/MyComponent.wsc")
Internet Explorer 5.0 supports DHTML Behavior syntax for creating instances of script components, which works somewhat differently than the traditional syntax for instantiating objects and will ensure that the script component cannot access potential unsafe system objects. For an example, see Using DHTML Behaviors on the Microsoft Site Builder Network (SBN) Web site.
Creating Remote Instances of Script Components
If the remotable attribute of a script component's <registration> element has been set to "true," the script component can be instantiated remotely from another computer using Distributed COM (DCOM).
Both computers must have basic DCOM installed. A computer is correctly configured with DCOM if it is running any of the following:
Windows NT 4.0, Windows 98, Windows Millennium Edition, Windows 2000, or Windows XP
Windows 95 running Internet Explorer 4.0
Windows 95 with the OEM Service Release 2 (OSR2) or later. For details, see the Windows 95 OSR2 page on the Microsoft Web site.
Windows 95 with DCOM for Windows 95, version 1.2. For details, see the DCOM for Windows 95 page on the Microsoft Web site.
The script component itself must be deployed as follows:
On the local computer, you do not require either the script component itself (.wsc file) or the script component run-time (Scrobj.dll) at the time you instantiate the script component. However, you must have a reference to the remote script component in the local Windows registry for DCOM. For details, see Registering a Script Component.
On the remote computer, you require the script component and the script component runtime. Both must be registered.
When you create an instance of a remote script component, it works within your application as if it were a local object; you call its methods and get and set its properties normally. However, the remote script component's script runs on the remote machine and has access to that machine's resources (within any limitations imposed by security, and so forth). Communication between the host application on the local machine and the script component on the remote machine is handled automatically and invisibly by DCOM.
To create a remote instance of a script component, call the CreateObject method, passing it the name of the remote computer as a parameter.
Note
The ability to use CreateObject for instantiating remote script components requires Visual Basic 6.0 or later or VBScript 5.0 or later.
The following Visual Basic example shows how to do this on a computer named "myserver":
Set newS = CreateObject("Component.MyComponent", "myserver")
Note
There can be a slight delay when you first instantiate a remote script component while DCOM establishes communication between the computers.
See Also
Creating Registration Information
Creating Script Components
How Script Components Work
Introducing Windows Script Components
Registering a Script Component