|
|
| Thema: |
Scripting Host |
| |
Die Einführung des Windows Scripting Hosts (WSH) mit Windows 98 (für
Windows 95 nachinstallierbar unter,
Datei WSH.EXE, 567 KB) war ein Schnellschuss: Der WSH offenbart so
manche Ungereimtheit. Abgesehen von Programmierproblemen erweist sich
auch, dass einige Ausführungs-Optionen der Scripts undokumentiert
oder gar fehlerhaft sind.
1. Versteckter Batchmode. Wenn Sie auf ein VB- oder J-Script
rechtsklicken, führt Sie das Kontextmenü "Eigenschaften"
zu einem Dialog mit dem Registerblatt "Skript". Sobald Sie
hier eine Änderung vornehmen, legt Windows eine neue Datei mit der
Endung WSH an, die die gewünschten Eigenschaften speichert. Die
derzeit einzige wesentliche Option ist ein Zeitlimit: So kann es
zweckmässig sein, die Meldung eines simplen VB-Scripts wie
msgbox date(),64,"Heutiges Datum: "
nach wenigen Sekunden automatisch zu beenden, um sich den OK-Klick zu
ersparen. Dies lässt sich über "Skript nach angegebener Zeit
anhalten" sekundengenau steuern.
Ein Blick in eine WSH-Datei zeigt eine weitere Option, die der
Eigenschaften-Dialog nicht preisgibt: "BatchMode=0" steht
dort standardmässig. Mit dem Wert "1" erreichen Sie, dass
das zugeordnete Script komplett im Hintergrund abläuft. Das kann
praktisch sein, hat aber seine Tücken: Sie müssen in Ihrem Script
dann nämlich auf jeden Eingabedialog verzichten; ein solcher Dialog
wird weder übergangen noch mit einer Fehlermeldung quittiert, sondern
führt schlicht zum Abbruch.
2. WSH oder VBS starten. Verwirrend ist ferner der Status der
WSH-Dateien an sich: Gekennzeichnet sind sie mit einem Verknüpfungspfeil,
so dass der Vergleich mit den PIF-Dateien für DOS-Programme
naheliegt. Anders als dort gelten jedoch die Optionen einer zu einem
Script gehörigen WSH-Datei nur dann, wenn die WSH-Datei direkt
aufgerufen wird. Ein VB-Script übernimmt beim Doppelklick immer die
Standardeinstellungen der Registry
(Hkey_Current_User\Software\Microsoft\Windows Scripting
Host\Settings), selbst wenn im selben Verzeichnis eine gleichnamige
Datei mit der Endung WSH existiert.
3. Kein Drag & Drop. Ein weiteres Problem: VB- oder J-Scripts sind
nicht Drag&Drop-fähig. Dieser Mangel lässt sich nach unserer
Kenntnis weder durch Links zum Script noch durch Links zur
WSH-Informationsdatei noch durch Registry-Änderungen beheben - und
das ist umso ärgerlicher, als übergebene Parameter im Script
problemlos zu verarbeiten wären:
set objargs=wscript.arguments
if objargs(0) <> "" then wscript.echo objargs(0)
Die Parameterverarbeitung funktioniert anstandslos, wenn Sie das
Script mit "wscript <name>.vbs parameter" in der
Kommandozeile ("Start, Ausführen") abrufen. Derzeit
erreichen Sie Drag&Drop-Funktionalität nur über einen nicht sehr
eleganten Weg: Sie müssen eine Batchdatei dazwischenschieben, die die
Parameter an das eigentliche Script weitergibt ("wscript xyz.vbs
%1 %2 %3").
4. Optimierbarer Registry-Standard. Dass Microsoft an die
Parameterweitergabe nicht ernsthaft gedacht hat, zeigt sich auch an
der Registry-Einstellung
"Hkey_Classes_Root\VBSFile" beziehungsweise
"...\JSFile": Als "Command" finden Sie dort:
script.exe "%1" %*
Es ist also nur ein Parameter vorgesehen. Mit zwei zusätzlichen Anführungszeichen
wscript.exe "%1" "%*"
erlauben Sie die Übernahme von mehr als nur einem Parameter. |
|
