Comportement GetObject et CreateObject des serveurs Office Automation

Résumé

Cet article décrit les différents comportements qui se produisent lorsque vous utilisez les fonctions GetObject et CreateObject avec différentes versions des applications Microsoft Office.

GetObject et CreateObject sont des fonctions fournies par Microsoft Visual Basic et Microsoft Visual Basic pour Applications (VBA). Toutefois, les informations s’appliquent également à Microsoft Visual C++ si vous traitez les références à GetObject comme des appels à l’API GetActiveObject, et les références à CreateObject en tant qu’appels à l’API CoCreateInstance.

Informations supplémentaires

GetObject

GetObject est utilisé pour attacher un instance en cours d’exécution d’un serveur Automation. Il existe plusieurs façons d’appeler GetObject, mais la syntaxe recommandée pour les applications Microsoft Office est la suivante :

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

Si un instance de Microsoft Excel est en cours d’exécution lors de l’exécution de ce code, vous avez accès au modèle objet de l’instance en cours d’exécution via la variable xlApp. Si aucune instance n’est en cours d’exécution, vous recevez le message d’erreur d’exécution interceptable suivant :

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

Si plusieurs instances de Microsoft Excel sont en cours d’exécution, GetObject s’attache au instance qui est lancé en premier. Si vous fermez ensuite la première instance, un autre appel à GetObject s’attache à la deuxième instance qui a été lancée, et ainsi de suite.

Vous pouvez joindre à un instance spécifique si vous connaissez le nom d’un document ouvert dans ce instance. Par exemple, si une instance d’Excel s’exécute avec un classeur ouvert nommé Book2, le code suivant s’attache correctement à cette instance même s’il ne s’agit pas du premier instance qui a été lancé :

Set xlApp = GetObject("Book2").Application

CreateObject

CreateObject est utilisé pour démarrer une nouvelle instance d’un serveur Automation. Par exemple :

set xlApp = CreateObject("Excel.Application")

Selon que le serveur est conçu comme SingleUse ou MultiUse, un autre processus serveur peut ou non être lancé. Il peut s’agir d’une distinction importante pour décider si vous devez arrêter de force une instance Automation. Par exemple, avec un serveur Multi-Utilisation, si une instance est déjà en cours d’exécution avant de l’attacher, vous pouvez éviter d’arrêter le serveur par programmation lorsque vous avez terminé de l’automatiser.

Le tableau suivant sert de référence utile lors de l’implémentation d’une solution avec Microsoft Office. Il répertorie les comportements et les attributs des différentes versions et applications de Microsoft Office, par exemple si le serveur est visible par défaut lors du lancement, s’il est SingleUse ou MultiUse, s’il a une propriété UserControl, s’il a une méthode Quit et le nom de classe de sa fenêtre main.

Le nom de classe de fenêtre main est utile pour appeler l’API FindWindow lorsque vous souhaitez savoir facilement si une instance est déjà en cours d’exécution. La propriété UserControl est une propriété booléenne qui indique si l’application serveur s’arrête automatiquement lors de la publication de sa dernière référence (définie sur rien). La méthode Quit vous permet de remplacer la propriété UserControl dans les cas où cela est nécessaire (par exemple, lorsqu’un instance ne s’arrête pas après la publication de la dernière référence).

En règle générale, Microsoft vous recommande d’utiliser une nouvelle instance d’une application Office au lieu de l’attacher à un instance que l’utilisateur peut utiliser. Il est préférable de créer un instance à l’aide du ProgID d’application, puis d’ouvrir ou de créer des objets à partir de là. Autres ProgID, tels que Excel.Sheet et Word. Les documents, et ainsi de suite, sont destinés à être utilisés dans OLE (Liaison d’objets et incorporation) et peuvent donner des résultats incohérents lorsqu’ils sont utilisés avec CreateObject. En utilisant application ProgID, vous évitez les problèmes potentiels en démarrant explicitement le serveur pour Automation (et non l’incorporation).

Lorsque vous avez terminé avec le serveur Automation, relâchez toutes vos références à celui-ci et appelez sa méthode Quit (si disponible) afin que le serveur s’arrête comme prévu. Si vous souhaitez configurer un instance via Automation, puis le laisser ouvert à l’utilisateur, vous devez définir la propriété UserControl sur TRUE, puis libérer toutes vos références. Le serveur reste ensuite en cours d’exécution (car la propriété UserControl a la valeur TRUE) et s’arrête de manière appropriée lorsque l’utilisateur ferme l’application (car il n’y a aucune référence en attente).

Note Par Word, la propriété UserControl est en lecture seule. Il ne peut pas être défini sur True ou False. Word reste toujours en cours d’exécution lorsque la dernière référence est publiée.