the wScript object and QTP
Trying to use the <font color="blue">wScript</font> object, which is the root object in the Windows Script Host (WSH) environment, in your QTP test scripts (or included libs)? If so read on.
The QTP online documentation includes the Microsoft vbScript online help documentation to support non-QTP information about using vbScript. You therefore get the impression when using QTP's combined online help that all WSH objects and features are available to you in QTP. This is incorrect. In at least the case of the wScript object (which is always present and instantiated in the WSH environment), it is not available in QTP.
Mercury has apparently posted a support article on this issue, which you can search for a view on their site if you under a support contract. The problem has already been summarized on this site, refer to the forum article by using this link:
The remainder of this post provides some addition information on this issue.
First, some posts on this site suggest that you can create the wScript object in QTP using the following command:
set wScript = CreateObject("WScript.Shell")
This does not create a wScript object. Rather this statement creates a native windows shell automation object.
While the wScript.CreateObject() method is not support in QTP, the CreateObject() function is supported in the QTP environment, so that it is possible to create irtually all types of automation objects (see above paragraph) in a QTP test (or a lib included by the test).
The issue of using the wScript object does not come up very often, in the context of writing QTP test cases. But if you are trying to develop shared vbScript libraries you will probably find it useful to initially develop those libs under WSH and then include them your QTP tests. In this scenario you may then discover that you used some wScript methods and properties that won't work in QTP. This author feels you have the following options at that point:
1. You can search and replace all wScript.blah references with the
equivalent QTP function or method call. But now you can't easily
extend/debug your lib later in the WSH environment (and we
always want to extend/change/fix/debug libs...)
2. Use an intermediate function or method call that will conditionally
execute the wScript.blah statements in the WSH environment
and QTP equivalent statements in the QTP environment. Refer to
the forum article, which uses this technique to implement
wScript.Sleep()/Wait(), using the link provided above.
3. You can create a wScript class/object in your QTP test (or more
realistically in a global lib included by all tests). Then you
can choose to implement those wScript methods and properties
used by your tests and libs, as needed.
Options #2 and #3 both have the downside that your QTP tests become less and less sharable with those not using your library or framework. But either of these options are probably better than option 1, if you: (a) code substantial general purpose libs which you want to develop and debug in WSH; and (2) you have strong control over the framework
and libs used by your QTP development team.
Also worth considering--this article only talks about WSH-unique objects used in your libs, but not supported in QTP. The reverse, QTP-unique objects used in your libs, can create the reverse problem if you are trying to primarily develop/debug in WSH. In that case you need to use one of the above techniques, as well to solve that problem (or, perhaps more realistically, develop soley in the QTP environment at that point).
Hope this is useful.
Re: the wScript object and QTP
Re: the wScript object and QTP
Another great scripting post Terry, keep up the good work.