Eine kurze Einführung
COM steht für "Component Object Model" und bezeichnet Microsofts Weg, Software über eine gemeinsame Schnittstelle miteinander zu verbinden. Die Interfaces sind in einem COM-Objekt definiert.
Bevor es COM gab, musste man die genaue Implementierung eines Programms kennen, um mit ihm zu interagieren. Mit COM können nun die definierten Objekte des Programms angesprochen werden. Die einzigen Dinge, die man über das Programm wissen muss, sind die Namen der benutzten Objekte und welche Eigenschaften und Methoden sie veröffentlichen.
Das sind die beiden grundlegenden Merkmale eines Objekts. Man kann die Eigenschaften (properties) als gespeicherte Daten eines Objekts betrachten. Eine Methode kann als interner Funktionsaufruf angesehen werden, der eine Operation mit den Daten ausführt.
Es kommt darauf an. AutoIt verfügt über eine Vielzahl eingebauter Funktionen und eine riesige Bibliothek von benutzerdefinierten Funktionen (UDF). Die meisten Programmieraufgaben können damit gelöst werden. Wenn aber besonderer Zugriff auf andere Applikationen erforderlich ist, kann COM einige Zeilen Code sparen. Skriptprogrammierer müssen aber beachten, dass die Existenz der COM-Objekte extrem abhängig vom verwendeten Betriebssystem und der installierten Software ist. Die folgenden Beispiele wurden alle unter einem 'gewöhnlichen' Windows XP Professional mit Microsoft Office 2000 getestet.
Angenommen, man wollte alle geöffneten Fenster minimieren. Man könnte dies mit den üblichen AutoIt-Funktionen wie WinList und WinSetState erledigen. Die folgenden zwei Zeilen COM-Code führen schneller zum Ziel:
$oShell = ObjCreate("shell.application")
$oShell.MinimizeAll
Anmerkung: Das Beispiel ist nicht mehr der kürzeste Weg, um alle Fenster zu minimieren, seit die Funktion WinMinimizeAll() in AutoIt eingeführt wurde.
In der ersten Zeile wird eine neue Instanz des Objekts namens "shell.application" erzeugt. Hierbei handelt es sich um ein Windows-internes Objekt, das in der shell32.dll definiert ist. Der zurückgegebene Zeiger auf das Objekt wird der Variablen $oShell zugewiesen. $oShell ist ab jetzt eine Objektvariable.
In der zweiten Zeile wird die Methode "MinimizeAll" auf das oShell-Objekt angewendet. Dadurch werden alle Fenster minimiert.
Alle Windows-Versionen verfügen über eine Unmenge interner Objekte für die verschiedensten Zwecke. Anwendungen wie Excel oder Word besitzen wiederum ihren eigenen Satz von Objekten.
Allerdings ist es manchmal schwierig, eine Liste aller im System existierenden Objekte mit den dazugehörigen Eigenschaften und Methoden zu erhalten. Eine Suche auf MSDN oder Google kann wertvolle Anhaltspunkte zum Objekt 'X', das benutzt werden soll, ergeben.
Beispielsweise können Informationen über das Objekt "shell.application" hier gefunden werden: http://msdn.microsoft.com/en-us/library/bb774094.aspx
Um einen Überblick über alle derzeitig im System vorhandenen Objekte zu erhalten, kann das Tool "OLE-COM-Objektkatalog" wertvolle Dienste leisten. Dieses Tool wird später in einem separaten Abschnitt behandelt.
Kommen wir zu einem weiteren Beispiel. Es soll der HTML-Quellcode einer bestimmten Internetseite ermittelt werden. Man könnte die interne Funktion InetGet() verwenden, um das Ergebnis in einer Datei zu speichern und anschließend mit FileRead() einzulesen. Aber dieser Code erledigt die Aufgabe eleganter:
$oHTTP = ObjCreate("winhttp.winhttprequest.5.1")
$oHTTP.Open("GET","http://www.AutoIt.de")
$oHTTP.Send()
$HTMLSource = $oHTTP.Responsetext
Die (String-) Variable $HTMLSource enthält nun den Kompletten HTML-Code der AutoIt.de-Homepage (sprich das oberste HTML-Frame).
Informationen über das "winhttp.winhttprequest"-Objekt können hier nachgelesen werden: http://msdn.microsoft.com/en-us/library/aa384106.aspx
Zur Erinnerung: Die Existenz von Objekten hängt vom Betriebssystem und den installierten Programmen ab. Zum Beispiel existiert das Objekt winhttp.winhttprequest.5.1 nur auf Computern, auf denen mindestens die Internet Explorer-Version 5 installiert ist. Wenn Skripte weitergegeben werden sollen, die COM-Objekte verwenden, muss sichergestellt sein, dass diese Objekte auf allen Computern vorhanden sind.
Objektvariablen verhalten sich etwas anders als andere Arten von Variablen in AutoIt. Ein Objekt ist kein realer Wert, sondern ein 'Zeiger' auf irgendetwas außerhalb des Skripts. Darum können weder Berechnungen noch Vergleiche mit Objektvariablen ausgeführt werden. Wenn einer Objektvariablen ein anderer Wert zugewiesen wird, wird der 'Zeiger' automatisch freigegeben. Die Freigabe eines Objekts kann beispielsweise dadurch erzwungen werden, dass der Objektvariablen eine Zahl oder ein Textwert zugewiesen wird:
$oHTTP = ObjCreate("winhttp.winhttprequest.5.1") ; Objekt wurde instanziert
$oHTTP=0 ; Objekt wurde freigegeben.
Objekte müssen nicht freigegeben werden, wenn ihre Verwendung abgeschlossen ist. Wenn ein Skript beendet wird, versucht AutoIt, alle aktiven Verweise auf in diesem Skript instanzierte Objekte freizugeben. Das gleiche geschieht, wenn in einer Funktion eine lokale Objektvariable definiert wurde und die Funktion mit Return beendet wird.
Eine sehr verbreitete Verwendung des COM ist die Automatisierung von Programmen. Anstelle der Verwendung normaler AutoIt-Funktionen wie Send() oder WinActivate() können Objekte benutzt werden, die innerhalb der Zielanwendung definiert wurden.
Hier folgt ein Beispiel zur Automatisierung von Microsoft Excel:
$oExcel = ObjCreate("Excel.Application") ; Instanziert ein Excel-Objekt
$oExcel.Visible = 1 ; Lässt Excel sich selbst anzeigen
$oExcel.WorkBooks.Add ; Fügt eine neue Arbeitsmappe hinzu
$oExcel.ActiveWorkBook.ActiveSheet.Cells(1,1).Value="Test" ; Füllt eine Zelle
Sleep(4000) ; Zeigt das Ergebnis 4 Sekunden lang an
$oExcel.ActiveWorkBook.Saved = 1 ; Simuliert das Speichern der Arbeitsmappe
$oExcel.Quit ; Beendet Excel
Die Komplexität der Steuerung eines anderen Programms hängt vom jeweiligen Programm und nicht vom AutoIt-Skript ab. Wenn etwas nicht wie erwartet funktioniert, ist ein zu Rate ziehen der Programmdokumentation erfolgversprechender, als das Studium der AutoIt-Hilfe.
In AutoIt wurden zwei spezielle Anweisungen für die Arbeit mit COM integriert:
Die WITH/ENDWITH und die FOR/IN/NEXT Schleife.
Die WITH/ENDWITH-Anweisung stellt keine zusätzliche Funktionalität zur Verfügung, aber sie macht das Skript besser lesbar. Zum Beispiel kann das vorherige Beispiel auch so umgesetzt werden:
$oExcel = ObjCreate("Excel.Application") ; Instanziert ein Excel-Objekt
WITH $oExcel
.Visible = 1 ; Lässt Excel sich selbst anzeigen
.WorkBooks.Add ; Fügt eine neue Arbeitsmappe hinzu
.ActiveWorkBook.ActiveSheet.Cells(1,1).Value="Test" ; Füllt eine Zelle
Sleep(4000) ;Zeigt das Ergebnis 4 Sekunden lang an
.ActiveWorkBook.Saved = 1 ; Simuliert das Speichern der Arbeitsmappe
.Quit ; Beendet Excel
ENDWITH
Dieses Beispiel erspart nicht viel Tipparbeit, aber wenn ein Objekt lange Ketten von Eigenschaften- oder Methoden-Bezeichnern verwendet, können diese mit Hilfe der WITH-Anweisung deutlich verkürzt werden, was auch der Lesbarkeit zu Gute kommt.
Die FOR...IN-Schleife wird benötigt, wenn Collections verwendet werden. Collections sind spezielle Arten von Objekten, die aus mehreren Unterobjekten bestehen. Man kann sie als Arrays betrachten (tatsächlich funktioniert die FOR..IN-Anweisung auch mit Array-Variablen).
Das folgende Beispiel verwendet eine FOR..IN-Schleife mit einem normalen AutoIt-Array, es hat also nichts mit COM zu tun und soll nur das Funktionsprinzip verdeutlichen:
$String = "" ; Eine String-Variable zur Kontrolle der Ausgabe
$aArray[0]="a" ; Füllen des Arrays
$aArray[1]=0 ; mit mehreren
$aArray[2]=1.3434 ; unterschiedlichen
$aArray[3]="testestestest" ; Beispielwerten.
FOR $Element IN $aArray ; Hier beginnt die eigentliche Schleife...
$String = $String & $Element & @CRLF
NEXT
; Anzeige des Ergebnisses:
Msgbox(0,"For..IN Array-Test","Ergebnis: " & @CRLF & $String)
In den meisten Fällen können keine 'normalen' Objekt-Methoden verwendet werden, um die Elemente einer Collection abzufragen. In 'COM'-Termini ausgedrückt, müssen sie 'durchgezählt' werden. Hier kommt die FOR..IN-Schleife ins Spiel.
Das folgende Excel-Beispiel durchläuft die Zellen A1:N16 im aktuellen Arbeitsblatt. Wenn der Wert einer Zelle kleiner als 5 ist, ersetzt der Code ihn mit 0 (null):
$oExcel = ObjCreate("Excel.Application") ; Instanziert ein Excel-Objekt
$oExcel.Visible = 1 ; Lässt Excel sich selbst anzeigen
$oExcel.WorkBooks.Add ; Fügt eine neue Arbeitsmappe hinzu
Dim $arr[15][16] ; Diese Zeilen
For $i = 0 to 14 ; sind nur
For $j = 0 to 15 ; ein Beispiel
$arr[$i][$j] = $i ; um Werte zum Füllen
Next ; einiger Zellen zu erzeugen.
Next
$oExcel.activesheet.range("A1:O16").value = $arr ; Zellen mit den Beispielwerten füllen
Sleep(2000) ; Wartet 2 Sekunden
For $cell in $oExcel.ActiveSheet.Range("A1:O16")
If $cell.Value < 5 Then
$cell.Value = 0
Endif
Next
$oExcel.ActiveWorkBook.Saved = 1 ; Simuliert das Speichern der Arbeitsmappe
Sleep(2000) ; Vor dem Beenden 2 Sekunden warten
$oExcel.Quit ; Excel beenden
Die folgenden Möglichkeiten der AutoIt-COM-Schnittstelle erfordern profunde Kenntnis der COM-Ereignisse und der COM-Fehlerbehandlung.
Für Neulinge der COM-Programmierung halten die folgenden Quellen wertvolle Informationen bereit:
Die Bibel der COM-Programmierung ist das englische Buch "Inside OLE 2" von Kraig Brockschmidt (Microsoft Press).
Es gibt auch im Internet eine Fülle von Informationen zum Thema COM (ohne AutoIt-Bezug):
http://msdn.microsoft.com/en-us/library/ms694363.aspx (OLE-Überblick)
http://www.garybeene.com/vb/tut-obj.htm (engl.: Objekte in Visual Basic)
http://java.sun.com/docs/books/tutorial/java/concepts/ (engl.: Verwendung von Objekten in Java)
http://msdn.microsoft.com/de-de/library/awbftdfh(VS.80).aspx (Objekt-Ereignisse in C++)
http://www.garybeene.com/vb/tut-err.htm (engl.: Fehlerbehandlung in Visual Basic)
Die normale COM-Automation verwendet hauptsächlich Einweg-Kommunikation. Eine beliebige Eigenschaft oder
die Ergebnisse einer Methode werden abgefragt. Ein COM-Objekt kann aber dem Skript auch etwas erwidern,
wenn es dafür ausgelegt ist.
Das kann sehr praktisch sein, wenn auf das Auftreten bestimmter Aktionen mit COM-Bezug gewartet werden muss.
Statt eine Art Schleife zu verwenden, in der das Objekt gefragt wird, ob irgendetwas Interessantes passiert ist, kann man das Objekt selbst dazu veranlassen, eine bestimmte UDF im Skript aufzurufen. Inzwischen kann das Skript andere Aufgaben (nahezu) gleichzeitig erledigen.
Nicht alle Objekte unterstützen Ereignisse. Man muss die Objekt-Dokumentation sorgfältig lesen, um zu erfahren, ob das Objekt Ereignisse unterstützt oder nicht.
Wenn es Ereignisse untersützt, muss als nächtes ermittelt werden, welche Art von Ereignissen unterstützt werden. AutoItCOM kann nur Ereignisse vom Typ 'dispatch' empfangen.
Schließlich müssen noch die Namen der Ereignisse inklusive ihrer Argumente ermittelt werden, die das Objekt generieren kann (wenn vorhanden).
Nur wenn alle diese Informationen bekannt sind, kann mit der Entwicklung des AutoIt-Skripts, das COM-Ereignisse benutzt, begonnen werden.
Es folgt ein Ausschnitt aus einem Skript, der das Entgegennehmen von Ereignissen des Internet Explorers demonstriert:
$oIE=ObjCreate("InternetExplorer.Application.1") ; Instanziert ein Internet Explorer Objekt
$EventObject=ObjEvent($oIE,"IEEvent_","DWebBrowserEvents") ; Startet den Ereignisempfang
$oIE.url= "http://www.autoitscript.com" ; Lädt eine Beispiel-Webseite
;Ab jetzt generiert das $oIE-Objekt Ereignisse, während die Webseite geladen wird.
;Sie werden in der folgenden Ereignisfunktion behandelt.
;Hier kann das Skript angehalten werden, bis der Benutzer beenden will.
...(eigener Code)...
$EventObject.stop ; Dem IE mitteilen, dass keine Ereignisse mehr empfangen werden
$EventObject=0 ; Zerstört das Ereigniss-Objekt
$oIE.quit ; Beende den IE
$oIE=0 ; IE aus dem Speicher entfernen (nicht wirklich notwendig)
Exit ; Ende des Hauptskripts
; Ein paar Internet Explorer Ereignisfunktionen
;
; Eine vollständige Liste aller IE-Ereignisfunktionen findet man in der
MSDN-WebBrowser-Dokumentation:
; http://msdn.microsoft.com/en-us/library/system.windows.forms.webbrowser.aspx
Func IEEvent_StatusTextChange($Text)
; Im compilierten ASkript (siehe Link weiter unten) wird der Inhalt einem Edit-Feld angezeigt.
GUICtrlSetData ( $GUIEdit, "IE-Statustext geändert zu: " & $Text & @CRLF, "append" )
EndFunc
Func IEEvent_BeforeNavigate($URL, $Flags, $TargetFrameName, $PostData, $Headers, $Cancel)
; Im compilierten ASkript (siehe Link weiter unten) wird der Inhalt einem Edit-Feld angezeigt.
; Hinweis: Die Deklaration unterscheidet sich von der im MSDN!
GUICtrlSetData ( $GUIEdit, "BeforeNavigate: " & $URL & " Flags: " & $Flags & @CRLF, "append")
EndFunc
Klicke hier, um das komplette Skript zu sehen.
Die wichtigste Zeile im Skript ist:
$EventObject=ObjEvent($oIE,"IEEvent_",...).
Diese Funktion übernimmt das Objekt $oIE
und leitet dessen Ereignisse auf AutoIt-Funktionen um, deren Namen mit
IEEvent_ beginnen. Der dritte Parameter
ist optional. Er wird benutzt, wenn das Objekt mehrere Ereignisschnittstellen besitzt
und AutoIt nicht automatisch eine davon auswählen soll.
Das für die ständige Umleitung der Ereignisse verantwortliche Objekt ist
$EventObject. Diese Variable benötigt keine weitere
Beachtung, außer wenn die Ereignisumleitung gestoppt werden soll.
Um die Umleitung der Ereignisse zu beenden, kann nicht einfach der Inhalt der Variable gelöscht werden (etwa so: $EventObject=""). Der Grund ist, dass das 'aufrufende' Objekt weiterhin einen Verweis zu dieser Variable hält und diesen nicht freigibt, solange das Objekt selbst existiert. Man könnte das Problem lösen, indem man das 'aufrufende' Objekt zerstört, aber man kann dem Objekt auch mitteilen, dass man keine Ereignisse mehr empfangen möchte: $EventObject.Stop. Danach kann man (muss man aber nicht) das Ereignis-Objekt durch Zuweisen eines beliebigen Wertes löschen, etwa so: $EventObject="".
Wenn man die Namen der Ereignisse kennt, die $oIE aussendet, kann die Behandlung der Ereignisse, an denen man interessiert ist, durch Erstellen von benutzerdefinierten Funktionen im eigenen Skript implementiert werden, indem man die Funktionen folgendermaßen benennt: IEEvent_Ereignisname(optionale Argumente). Dabei ist die korrekte Anzahl und Reihenfolge der Argumente zu beachten, so wie sie für das jeweilige Ereignis definiert sind. Anderenfalls wird es zu unerwarteten Ergebnissen führen.
Wenn man (egal aus welchem Grund) die Namen der Ereignisse nicht kennt, kann eine Funktion erstellt
werden, deren Name nur den Präfix enthält, in diesem Beispiel:
Func IEEvent_($Eventname). Wenn ein Ereignis empfangen wurde und
keine entsprechende Ereignisfunktion
(IEEvent_Ereignisname)
existiert, wird stattdessen diese allgemeine Ereignisfunktion aufgerufen und der Name des Ereignisses
in der Variablen $Eventname abgelegt.
Man muss nicht alle Ereignisse als Funktion implementieren. Jene die nicht implementiert sind, werden einfach ignoriert.
Mehr Beispielskripte zur Verwendung der COM-Ereignisfunktionen findet man unter: http://www.autoitscript.com/autoit3/files/beta/autoit/COM/
Einschränkungen beim Umgang mit COM-Ereignissen in AutoIt
Manche Objekte (wie 'WebBrowser') übergeben Argumente zu ihren Ereignisfunktionen als Referenz ('by ref'). Das erlaubt dem Anwender, diese Argumente zu verändern und das Objekt zurück zu geben. Allerdings verwendet AutoIt sein eigenes Variablen-Modell, das mit den COM-Variablen nicht kompatibel ist. Das bedeutet, das alle von Objekten übergebenen Werte in AutoIt-Variablen konvertiert werden müssen, wodurch die Referenz auf den originalen Speicherbereich verloren geht. Möglicherweise könnte in naher Zukunft diese Beschränkung entfallen.
Die Verwendung von COM ohne vernünftige Fehlerbehandlung ist sehr heikel. Besonders dann, wenn man mit den Objekten in seinem Skript nicht vertraut ist.
Ein AutoIt-Skript wird unmittelbar seine Ausführung abbrechen, wenn es einen COM-Fehler entdeckt. Das ist die Voreinstellung und auch die sicherste Einstellung. In diesem Fall müssen Maßnahmen im Skript getroffen werden, um das Auftreten von Fehlern zu verhindern.
Nur wenn es keine Möglichkeit gibt, einen COM-Fehler zu verhindern, kann ein "Error-Handler" implementiert werden, der Aktionen veranlasst, nachdem ein Fehler aufgetreten ist. Das ist keine Lösung, um ein fehlerhaftes Skript zum korrekten Arbeiten zu bringen. Es werden auch keine Fehler im Skript abgefangen, die nichts mit COM zu tun haben (z.B. Deklarations- und Syntaxfehler).
Die Fehlerbehandlung ist auf die gleiche Art wie die Behandlung der normalen COM-Ereignisse implementiert, es werden ObjEvent() und benutzerdefinierte COM-Ereignisfunktionen verwendet. Der einzige Unterschied ist die Verwendung der unveränderlichen Zeichenkette "AutoIt.Error" als Name des Objekts.
Ein Beispiel:
$oMyError = ObjEvent("AutoIt.Error","MyErrFunc") ; Implementiert einen eigenen Error-Handler
; Erzeugt absichtlich einen Fehler (Objekt existiert nicht)
$oIE = ObjCreate("InternetExplorer.Application")
$oIE.visible = 1
$oIE.bogus
if @error then Msgbox(0,"","Die vorherige Zeile lieferte einen Fehler!")
Exit
; Das ist unser eigener Error-Handler
Func MyErrFunc()
$HexNumber=hex($oMyError.number,8)
Msgbox(0,"","Ein COM-Fehler wurde abgefangen!" & @CRLF & _
"Fehlernummer: " & $HexNumber & @CRLF & _
"WinDescription: " & $oMyError.windescription )
SetError(1) ; Ein Rückgabewert zum Überprüfen, wen die Funktion zurückgekehrt ist
Endfunc
Etwas ist besonders am Error-Event-Handler, und das ist das Objekt, welches er zurückgibt. Das ist ein AutoIt-Error-Objekt, welches über einige nützliche Eigenschaften und Methoden verfügt. Dessen Implementierung ist teilweise an das "Err"-Objekt von VB(script) angelehnt:
Eigenschaften des AutoIt-Error-Objekts:
| .number | Der Windows-HRESULT-Wert eines COM-Aufrufes |
| .windescription | Der FormatWinError()-Text, der von .number abgeleitet wurde |
| .source | Name des Objekts, das den Fehler erzeugt hat (Inhalt von ExcepInfo.source) |
| .description | Fehlerbeschreibung des Quellobjekts (Inhalt von ExcepInfo.description) |
| .helpfile | Fehler-Hilfedatei des Quellobjekts (Inhalt von ExcepInfo.helpfile) |
| .helpcontext | Hilfedatei-Kontext-ID des Quellobjekts (Inhalt von ExcepInfo.helpcontext) |
| .lastdllerror | Die von GetLastError() gelieferte Nummer |
| .scriptline | Die Skriptzeile, in der der Fehler generiert wurde |
Methoden des AutoIt-Error-Objekts:
| .raise | Löst ein vom Anwender angestoßenes Fehlerereignis aus |
| .clear | Löscht den Inhalt des Error-Objekts (d.h. Zahlen auf 0, Zeichenketten auf "") |
Ein Hinweis für UDF-Autoren
Es kann nur EIN Error-Event-Handler pro AutoIt-Skript aktiv sein. Wenn UDFs geschrieben werden, die COM-Funktionen beinhalten, kann so überprüft werden, ob der Anwender einen Error-Handler installiert hat:
$sFuncName = ObjEvent("AutoIt.Error")
if $sFuncName <> "" then Msgbox (0,"Test","Der Anwender hat folgenden Error-Handler installiert: " & $sFuncName)
Wenn kein Error Handler aktiv ist, kann man vorübergehend einen eigenen Error-Handler während des UDF-Aufrufes installieren.
Allerdings kann man einen existierenden Error-Handler nicht beenden, ohne die Variable freizugeben, die ihm zugeordnet wurde. Wenn der Skript-Autor einen COM-Error-Handler installiert hatte, liegt es in seiner Verantwortung, eine geeignete Funktion zu verwenden, die auch die von UDFs generierten COM-Fehler abfangen kann.
Der "OLE-COM-Objektkatalog" ist ein sehr praktisches Werkzeug, um einen Überblick über alle COM-Objekte zu erhalten, die gegenwärtig im System installiert sind. Es ist Teil des Windows 2000 Resource Kits und kann hier heruntergeladen werden: http://www.microsoft.com/downloads/details.aspx?familyid=5233b70d-d9b2-4cb5-aeb6-45664be858b6&displaylang=en
Die Installation des Programms ist ein wenig plump. Es werden keine Startmenüeinträge erstellt. Stattdessen wird eine Datei namens oleview.exe in das Verzeichnis C:\Programme\Resource Kit installiert (Standard-Installation).
Wenn oleview.exe gestartet wird, reklamieren einige Systeme ein Fehlen der Datei iviewers.dll. Diese Datei wird benötigt, ist aber sonderbarerweise im aktuellen Installationspaket nicht enthalten. Man kann diese Dll aus einem älteren Installationspaket erhalten: http://download.microsoft.com/download/2/f/1/2f15a59b-6cd7-467b-8ff2-f162c3932235/ovi386.exe. Es installiert die Dateien standardmäßig nach C:\MSTOOLS\BIN. Es wird nur die Datei iviewer.dll benötigt. Sie muss ins selbe Verzeichnis kopiert werden, in dem sich auch die oleview.exe befindet, dann muss die Dll mit folgender Eingabe in die Kommandozeile registriert werden: regsvr32 iviewers.dll.
Sehen wir uns nun ein kleines Beispiel mit dem Oleviewer an. Nach dem Starten folgt man diesem Zweig:
Object Classes->Grouped by Component Category->Control->Microsoft Web Browser.
In der linken Spalte sieht man alle COM-Schnittstellen, die für das gewählte Objekt definiert sind. Dazu kommen wir später. Ein genauere Blick auf die rechte Spalte zeigt, dass sie eine Vielzahl von Informationen enthält, die für die Benutzung des Objekts in einem AutoIt-Skript von Bedeutung sind. Am wichtigsten ist die "VersionIndependentProgID". Das ist der Name, der in den Funktionen ObjCreate, ObjGet oder ObjEvent zu verwenden ist. Außerdem sind der Verzeichnis- und Dateiname enthalten, wo das Objekt zu finden ist. Dabei kann es sich um eine EXE-, DLL- oder OCX-Datei handeln. InProcServer32 bedeutet, dass das Objekt im selben Thread wie unser Skript läuft (in-process). Wenn LocalServer32 zu lesen ist, läuft das Objekt in einem eigenen Prozess. Das Objekt muss außerdem eine Typbibliothek enthalten (die Zeilen nach TypeLib="), sonst kann es nicht in einem AutoIt-Skript verwendet werden.
Die Schnittstellen in der linken Spalte werden verwendet, um verschiedene Arten der Interaktion mit dem Objekt zu realisieren. Einige sind für Speichervorgänge (IStorage, IPersist), andere für das Einbetten in ein GUI (IOleObject, IOleControl) zuständig. AutoIt verwendet die IDispatch-Schnittstelle für die Automatisierung. Diese Schnittstelle 'enthüllt' alle skriptfähigen Methoden und Eigenschaften, die das Objekt untersützt. Wenn sie nicht existiert, kann das Objekt nicht in einem AutoIt-Skript benutzt werden.
Schauen wir uns diese Schnittstelle genauer an. Rechtsklicken wir auf den Namen
IDispatch und wählen "View..."
im erscheinenden Kontextmenü aus. Nun klicken wir auf die Schaltfläche
"View TypeInfo...".
(Hinweis: Sollte die Schaltfläche ausgegraut sein, wurde die
iviewers.dll noch nicht registriert oder das Objekt enthält keine
Typbibliothek)
Das Fenster "ITypeInfo Viewer" zeigt nur die Informationen, die das Objekt bereitstellt. Wenn der Entwickler sich dazu entschlossen hat, keine Hilfedatei einzubinden, kann man nur die Namen der Methoden und Eigenschaften sehen, nichts weiter. Die "Microsoft Web Browser"-Typbibliothek dagegen ist ziemlich umfangreich. Klickt man einen Eintrag in der linken Spalte an, wird rechts eine Beschreibung angezeigt. Manchmal muss man "Inherited Interfaces" durchstöbern, um mehr Methoden des Objekts zu erhalten.
Die Syntax der beschriebenen Methoden und Eigenschaften ist im Stil von C/C++ dargestellt. Eine Eigenschaft, die als "HRESULT Resizable([in] VARIANT_BOOL pbOffline) " beschrieben wird, muss in etwa so für AutoIt umgeschrieben werden: $Resizable=$Object.Resizable ($Object enthält das Objekt, welches mit ObjCreate oder ObjGet erzeugt wurde).
Diese Begriffe werden häufig mit COM verwechselt, haben aber eine andere Bedeutung:
OOP = Object Oriented Programming
Eine Programmiertechnik, bei der Software-Komponenten aus
wiederverwendbaren Code-Bausteinen zusammengesetzt werden, bekannt als Objekte.
DDE = Dynamic Data Exchange
Man könnte sagen, das ist der Vorläufer von COM. Es benutzte IPC, um Informationen und Kommandos
zwischen verschiedenen Anwendungen auszutauschen.
OLE = Object Linking and Embedding
In seiner ersten Version war OLE eine erweiterte Version von DDE, um Daten aus einem Programm in ein
anderes 'einzubetten'. Die aktuelle Generation von OLE baut auf COM auf und ist Teil von ActiveX.
Automation = Automatisierung
Eine Möglichkeit, die Objekte anderer Anwendungen zu manipulieren. Wird in OLE, ActiveX
und COM verwendet.
ActiveX
Die nächste Generation von OLE mit Automation, usprünglich entwickelt, um Anwendungen über
ein Netzwerk zu verknüpfen (hauptsächlich Web-Browser). ActiveX baut auf COM auf.
DCOM = Distributed COM
Eine geringfügige Modifikation von COM, um zwischen verschiedenen physischen
Computern kommunizieren zu können.
.NET = Dot Net
Das ist nicht wirklich ein Stück Software, sondern eine 'Idee' von Microsoft,
um einfach 'Alles' mit deren Software zu vernetzen. "Dot Net" wird hauptsächlich für
Web-Anwendungen benutzt.
COMmunist = Kommunist
Das ist kein Unterstützer von COM, sondern jemand, der an den Kommunismus glaubt
(Eine Theorie, nach der das gemeine Volk im Besitz allen Eigentums sein sollte).