Joe
Thu Jan 22 11:33:50 CST 2004
Hi,
"Jens Lenge" <Spampot@gmx.net> wrote in message
news:buotoj$15v$03$1@news.t-online.com...
| Thanks for the hint, I will try that as soon as possible.
|
| BTW, just for understanding:
| Why may I create a shell object via CreateObject("WScript.Shell") even in
| environments where the WScript object itself is not accessible?
| Maybe I am caught in the C++ way of thinking, but I cannot see why it is
| possible to access a specific class member when the corresponding class
| itself is not present.
|
| Guess I didn't truly understand the VBScript object model?
Don't feel alone. This one confuses many people and threw me for a long
time. WScript.Shell is only syntactically a subobject of WScript.
Physically, its in a separate file. For an overview:
The immediate WScript object methods and properties are designed to work
only where WSH is the host. WSH is the host only where WSCRIPT.EXE and
CSCRIPT.EXE are run directly.
WSH comes with numerous DLL/OCX files, in addition to the EXE files. Each
scripting host that allows VBS/JS, accessess the various WSH DLL/OCX files,
as that host permits.
MS placed the only "immediate" WScript methods and properties (i.e., not
WScript.Shell) in the WSH EXE files, themselves, so they are not accessible
from other scripting hosts. (Credit Tom Lavedas for a post with this info.)
By comparison, the fundamental WScript.Shell object and the Err object are
exposed through other DLL/OCX files, and are available in other hosts, when
not suppressed for security reasons. MS apparently believes that the
immediate WScript methods and properties present a basic conflict or
security hazard with other hosts.
The WScript object can be passed into a WSC file through a defined property,
but I have not been successful in trying to pass it into any other hosts.
Joe Earnest
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (
http://www.grisoft.com).
Version: 6.0.564 / Virus Database: 356 - Release Date: 01-19-04