GetObject- und CreateObject-Verhalten von Office-Automatisierungsservern

Zusammenfassung

In diesem Artikel werden die verschiedenen Verhaltensweisen erläutert, die auftreten, wenn Sie die Funktionen GetObject und CreateObject mit verschiedenen Versionen von Microsoft Office-Anwendungen verwenden.

GetObject und CreateObject sind Funktionen, die von Microsoft Visual Basic und Microsoft Visual Basic for Applications (VBA) bereitgestellt werden. Die Informationen gelten jedoch auch für Microsoft Visual C++, wenn Sie Verweise auf GetObject als Aufrufe der GetActiveObject-API und Verweise auf CreateObject als Aufrufe der CoCreateInstanceAPI behandeln.

Weitere Informationen

GetObject

GetObject wird verwendet, um an eine ausgeführte instance eines Automatisierungsservers anzufügen. Es gibt verschiedene Möglichkeiten zum Aufrufen von GetObject, aber die Syntax, die für die Microsoft Office-Anwendungen empfohlen wird, lautet wie folgt:

set xlApp = GetObject(, "Excel.Application")

Wenn ein instance von Microsoft Excel ausgeführt wird, wenn dieser Code ausgeführt wird, haben Sie über die xlApp-Variable Zugriff auf das Objektmodell des ausgeführten instance. Wenn kein instance ausgeführt wird, erhalten Sie die folgende abfangbare Laufzeitfehlermeldung:

Run-time error '429':
ActiveX component can't create object  

Wenn mehrere Instanzen von Microsoft Excel ausgeführt werden, wird GetObject an die instance angefügt, die zuerst gestartet wird. Wenn Sie dann die erste instance schließen, wird ein weiterer Aufruf von GetObject an den zweiten instance angefügt, der gestartet wurde usw.

Sie können an eine bestimmte instance anfügen, wenn Sie den Namen eines geöffneten Dokuments in diesem instance kennen. Wenn beispielsweise eine instance von Excel mit einer geöffneten Arbeitsmappe mit dem Namen Book2 ausgeführt wird, wird der folgende Code erfolgreich an diese instance angefügt, auch wenn dies nicht der früheste instance ist, der gestartet wurde:

Set xlApp = GetObject("Book2").Application

CreateObject

CreateObject wird verwendet, um eine neue instance eines Automation-Servers zu starten. Beispiel:

set xlApp = CreateObject("Excel.Application")

Je nachdem, ob der Server als SingleUse oder MultiUse konzipiert ist, kann ein anderer Serverprozess gestartet werden. Dies kann ein wichtiger Unterschied bei der Entscheidung sein, ob Sie eine Automatisierungs-instance zwangsdeaktivieren sollten. Wenn beispielsweise bei einem MultiUse-Server bereits ein instance ausgeführt wird, bevor Sie ihn anfügen, sollten Sie das programmgesteuerte Herunterfahren des Servers vermeiden, wenn Sie die Automatisierung abgeschlossen haben.

Die folgende Tabelle dient als hilfreiche Referenz für die Implementierung einer Lösung mit Microsoft Office. Sie listet Verhalten und Attribute der verschiedenen Versionen und Anwendungen von Microsoft Office auf, z. B. ob der Server beim Starten standardmäßig sichtbar ist, ob er SingleUse oder MultiUse ist, ob er über eine UserControl-Eigenschaft verfügt, ob er über eine Quit-Methode verfügt, und den Klassennamen für sein Standard Fenster.

Der Name der Standard Fensterklasse ist hilfreich, um die FindWindow-API aufzurufen, wenn Sie bequem herausfinden möchten, ob bereits instance ausgeführt wird. Die UserControl-Eigenschaft ist eine boolesche Eigenschaft, die angibt, ob die Serveranwendung automatisch heruntergefahren wird, wenn ihr letzter Verweis freigegeben wird (auf nichts festgelegt). Mit der Quit-Methode können Sie die UserControl-Eigenschaft in Fällen überschreiben, in denen dies erforderlich ist (z. B. wenn ein instance nicht heruntergefahren wird, nachdem der letzte Verweis freigegeben wurde).

Im Allgemeinen empfiehlt Microsoft, dass Sie eine neue instance einer Office-Anwendung verwenden, anstatt an eine instance anzufügen, die der Benutzer möglicherweise verwendet. Erstellen Sie am besten eine instance mithilfe der Anwendungs-ProgID, und öffnen oder erstellen Sie dann von dort aus neue Objekte. Andere ProgIDs, z. B. Excel.Sheet und Word. Dokumente usw. sind für die Verwendung in OLE (Objektverknüpfung und Einbettung) vorgesehen und können bei Verwendung mit CreateObject inkonsistente Ergebnisse liefern. Durch die Verwendung der Anwendungs-ProgID vermeiden Sie potenzielle Probleme, indem Sie den Server explizit für die Automatisierung starten (nicht einbetten).

Wenn Sie mit dem Automation-Server fertig sind, geben Sie alle Ihre Verweise darauf frei, und rufen Sie die Quit-Methode (falls verfügbar) auf, damit der Server wie erwartet heruntergefahren wird. Wenn Sie eine instance über Automation konfigurieren und dann für den Benutzer geöffnet lassen möchten, müssen Sie die UserControl-Eigenschaft auf TRUE festlegen und dann alle Verweise freigeben. Der Server wird dann weiterhin ausgeführt (da die UserControl-Eigenschaft TRUE ist) und wird entsprechend heruntergefahren, wenn der Benutzer die Anwendung schließt (da keine ausstehenden Verweise vorhanden sind).

Hinweis Für Word ist die UserControl-Eigenschaft schreibgeschützt. Sie kann nicht auf True oder False festgelegt werden. Word wird immer ausgeführt, wenn der letzte Verweis freigegeben wird.