|
Also, VSH = Visual BASIC Scripting Host, das ist eine abgespeckte Variante von Visual BASIC von MS für Windows, eben eine nur-Skript-Sprache, die in den neueren Windows-Versionen inbegriffen ist. (Unter W95 musste man sich VSH wohl noch herunterladen und selbst installieren, in neueren Versionen sollte VSH dabei sein.) Wenn einfach vom "Windows Scripting Host" oder "Scripting Host" die Rede ist, ist meist VSH gemeint - obwohl z. B. BM auch ein Scripting Host ist.
Die Bezeichnung OLE ist in diesem Zusammenhang nicht ganz richtig, im Grunde geht es um den objektorientierten Aufruf von "Objekten" - das kann alles Mögliche sein, Programme, Komponenten des Systems, DLLs usw. Sind diese unter Windows installiert, so stellen sie standardisierte Aufrufe zur Verfügung, über die Daten ausgetauscht werden können, aber auch Befehle und Anweisungen. Im Prinzip ist dies eine geniale Sache: Statt in jeder Anwendung dieselben Probleme immer wieder neu zu lösen, delegiert man sie einfach an ein "Objekt", das die Lösung bereits implementiert hat. Z. B. kann man auf einem Windows-System den Zeilenumbruch eines Textes mittels objektorientiertem Aufruf einfach an das Objekt Word.Application weiterleiten, dann bekommt man den Text umgebrochen zurück. Daran sieht man aber gleich auch, wo das Problem liegt: Auf verschiedenen Systemen gibt es verschiedene Objekte, wenn man also etwa statt Word SMO installiert hat, geht der erwähnte Aufruf natürlich ins Leere.
Ein Aufruf erfolgt folgendermassen: Man muss zuerst eine Verbindung zu einem Objekt herstellen. Dies erfolgt in BM mittels Set xy = Create.Object ("Name.Typ"). Dabei tritt schon zum ersten Mal die "Punktnotation" auf: Bei objektorientierten Aufrufen werden die einzelnen Teile mittels Punkten getrennt, aber ansonsten zusammen geschrieben. Beim Aufruf eines Objekts muss der Typ genannt werden, das ist bei Anwendungen in aller Regel Application, also etwa Shell.Application oder TextMaker.Application.
Wenn man mit Create.Object eine Verbindung hergestellt hat, dann kann man über die zugewiesene Variable (im Beispiel xy) alle Komponenten dieses Objekts ansprechen, also etwa so: xy.Methode.Aktion. In unserem Script etwa ist das aufzurufende Objekt die Shell vom Typ Application, also Shell.Application. Da wir dem Objekt die Variable sl zugewiesen haben, muss man nun aber nicht etwa schreiben: Shell.Methode oder: sl.Shell.Methode, sondern sl ersetzt "Shell", also: sl.Explorer. Ebenso tm statt TextMaker.
Nun unterscheidet man bei Objekten Methoden und Eigenschaften. Eine Methode ist immer irgendwie mit einer Aktion verbunden, entspricht also dem klassischen Befehl bzw. der Anweisung. Hinzu können Argumente bzw. Optionen kommen. In unserem Script ist eine Methode "Explore", sprich: öffne ein Explorer-Fenster. Diese Methode gehört zum Objekt Shell, das wir unter der Variable sl ansprechen, also lautet der Aufruf: sl.Explore. Als Argument müssen wir nun noch den Pfad angeben, dem wir die Variable pfad zugeordnet hatten.
In unserem Script kommt auch ein Aufruf mit einer Eigenschaft vor: tm.ActiveDocument.path ist ein solcher Aufruf, denn tm steht für das Objekt TextMaker, darin gibt es die Sammlung von Eigenschaften namens ActiveDocument, und darin enthalten ist die Eigenschaft path, auf die wir es abgesehen haben. Da nun dieser Aufruf eigentlich in einer Information besteht, da man sagen könnte, tm.ActiveDocument.path stelle diese Information symbolisch dar, so müssen wir, damit wir diese auch auslesen können, einer Variable zuweisen. (Alternativ könnte man auch versuchen: sl.Explore tm.ActiveDocument.path - ich bin aber eher gegen solche Schreibweisen.) Umgekehrt kann es auch vorkommen, dass man einem Objekt eine Eigenschaft zuweisen möchte. Das ist etwa der Fall bei tm.Application.Visible = true, wobei gleichsam die linke und rechte Seite getauscht werden.
Soweit mal ein Crashkurs in Objektaufrufen. Das Dumme an der Sache ist, dass jedes Objekt unter einem bestimmten Namen aufgerufen werden muss, dass seine Methoden und Eigenschaften bestimmte Aufrufnamen tragen und dass es eben auch noch bestimmte Formalitäten für die Argumente gibt. Dazu braucht man Referenzen. Anders gesagt: Damit man mit Objekten etwas anfangen kann, muss man alles Nötige über sie wissen.
Nun, bei Shell.Explore pfad hat sich ja inzwischen gezeigt, dass es eben wirklich so ist, dass nur der Typ Variant akzeptiert wird, nicht aber etwa String o. dgl. Damit haben wir den "Übeltäter" in diesem Fall also identifiziert. Unter VSH ist es ja auch so, dass grundsätzlich einfach losgelegt werden kann, ohne auf Typen zu achten. Das ist (vor allem auch für Anfänger) praktisch, hat aber auch Nachteile, gerade auch dann, wenn man, wie hier, mit expliziten Typbezeichnern arbeiten will. Im professionellen Visual BASIC ist das m. W. dann eben auch gerade nicht so.
|
Anmelden
Registrieren
FAQ
Suche
