GetObject- und CreateObject-Verhalten von Office-Automatisierungsservern

Übersicht

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

GetObject und CreateObject sind Funktionen, die von Microsoft Visual Basic und Microsoft Visual Basic für Applikationen (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 eine ausgeführte Instanz eines Automatisierungsservers anzufügen. Es gibt einige verschiedene Methoden zum Aufrufen von GetObject, aber die für microsoft Office-App lications empfohlene Syntax lautet wie folgt:

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

Wenn eine Instanz von Microsoft Excel ausgeführt wird, wenn dieser Code ausgeführt wird, haben Sie Zugriff auf das Objektmodell der ausgeführten Instanz über die xlApp-Variable. Wenn keine Instanz 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, fügt GetObject an die Instanz an, die zuerst gestartet wird. Wenn Sie dann die erste Instanz schließen, wird ein weiterer Aufruf von GetObject an die zweite instanz angefügt, die gestartet wurde usw.

Sie können an eine bestimmte Instanz anhängen, wenn Sie den Namen eines geöffneten Dokuments in dieser Instanz kennen. Wenn z. B. eine Instanz von Excel mit einer geöffneten Arbeitsmappe namens Book2 ausgeführt wird, wird der folgende Code erfolgreich an diese Instanz angefügt, auch wenn es sich nicht um die früheste Instanz handelt, die gestartet wurde:

Set xlApp = GetObject("Book2").Application

CreateObject

CreateObject wird verwendet, um eine neue Instanz eines Automatisierungsservers zu starten. Zum Beispiel:

set xlApp = CreateObject("Excel.Application")

Je nachdem, ob der Server als SingleUse oder MultiUse konzipiert ist, wird möglicherweise ein anderer Serverprozess gestartet oder nicht gestartet. Dies kann eine wichtige Unterscheidung sein, um zu entscheiden, ob Sie eine Automatisierungsinstanz forcibly herunterfahren sollten. Wenn z. B. eine Instanz bereits ausgeführt wird, bevor Sie sie anfügen, sollten Sie das programmgesteuerte Herunterfahren des Servers vermeiden, wenn Sie damit fertig sind, den Server zu automatisieren.

Die folgende Tabelle dient als hilfreicher Verweis bei der Implementierung einer Lösung mit Microsoft Office. Es listet Verhalten und Attribute der verschiedenen Versionen und Anwendungen von Microsoft Office auf, z. B. ob der Server standardmäßig sichtbar ist, wenn es singleUse oder MultiUse ist, wenn es über eine UserControl-Eigenschaft verfügt, wenn sie über eine Quit-Methode verfügt, und den Klassennamen für das Hauptfenster.

Anwendung(en)	Sichtbar	Instanziierung	Has UserControl	Has QuitClassName	Klassenname
Excel 97, 2000, 2002, 2003, 2007	No	SingleUse	Ja	Ja	XlMain
Word 97, 2000, 2002, 2003, 2007	No	SingleUse	Ja	Ja	OpusApp
PowerPoint 97	No	MultiUse	No	Ja	PP97FrameClass
PowerPoint 2000	No	MultiUse	No	Ja	PP9FrameClass
PowerPoint 2002	No	MultiUse	No	Ja	PP10FrameClass
PowerPoint 2003	No	MultiUse	No	Ja	PP11FrameClass
PowerPoint 2007	No	MultiUse	No	Ja	PP12FrameClass
Access 97	Ja	SingleUse	Ja	Ja	OMain
Access 2000, 2002, 2003, 2007	No	SingleUse	Ja	Ja	OMain
Project 98, 2000	No	MultiUse	Ja	Ja	JWinproj-WhimperMainClass

Der Name der Hauptfensterklasse ist hilfreich, um die FindWindow-API aufzurufen, wenn Sie bequem herausfinden möchten, ob bereits eine Instanz ausgeführt wird. Die UserControl-Eigenschaft ist eine boolesche Eigenschaft, die angibt, ob die Serveranwendung automatisch heruntergefahren wird, wenn der letzte 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 eine Instanz nach der letzten Veröffentlichung des Verweises nicht heruntergefahren wird).

Im Allgemeinen empfiehlt Microsoft, eine neue Instanz einer Office-App lizenzierung zu verwenden, anstatt an eine Instanz anzufügen, die der Benutzer verwenden kann. Es ist am besten, eine Instanz mithilfe der Application ProgID zu erstellen und dann neue Objekte von dort aus zu öffnen oder zu erstellen. Andere ProgIDs wie Excel.Sheet und Word.Document usw. sind für die Verwendung in OLE (Objektverknüpfung und Einbettung) vorgesehen und können bei Verwendung mit CreateObject inkonsistente Ergebnisse liefern. Mithilfe der Application ProgID vermeiden Sie potenzielle Probleme, indem Sie den Server für die Automatisierung explizit starten (nicht einbetten).

Wenn Sie mit dem Automatisierungsserver fertig sind, geben Sie alle Ihre Verweise darauf frei, und rufen Sie die Quit-Methode (sofern verfügbar) auf, damit der Server wie erwartet heruntergefahren wird. Wenn Sie eine Instanz über Automatisierung 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 bleibt dann ausgeführt (da die UserControl-Eigenschaft WAHR 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. Er kann nicht auf "True" oder "False" festgelegt werden. Word wird immer ausgeführt, wenn der letzte Verweis freigegeben wird.