Partager via

Modèles objet compatibles avec InfoPath 2003

  • Article

Microsoft Office InfoPath 2007 est conçu comme une application COM (Component Object Model) et offre l'accès à ses interfaces de programmation à la fois pour l'automatisation externe et pour les scripts utilisés depuis des modèles de formulaires comme interfaces COM. Pour permettre la création de solutions InfoPath qui utilisent les langages de code managé de Visual C# et Visual Basic, le programme d'installation d'InfoPath installe trois assemblys d'interopérabilité. Les assemblys d'interopérabilité sont des assemblys .NET qui font office de lien entre le code managé et le code non managé et qui appliquent une correspondance entre les membres des objets COM et les membres managés équivalents de .NET.

Les fichiers des trois assemblys d'interopérabilité installés par InfoPath sont les suivants :

  • Microsoft.Office.Interop.InfoPath.dll

  • Microsoft.Office.Interop.InfoPath.SemiTrust.dll

  • Microsoft.Office.Interop.InfoPath.Xml.dll

Cette rubrique présente le modèle objet exposé dans l'assembly d'interopérabilité Microsoft.Office.Interop.InfoPath.SemiTrust, utilisé exclusivement pour la création et l'exécution d'une logique métier avec code managé depuis les modèles de formulaires InfoPath (.xsn).

Pour plus d'informations sur les assemblys Microsoft.Office.Interop.InfoPath et Microsoft.Office.Interop.InfoPath.Xml, utilisés exclusivement pour l'automatisation d'InfoPath à l'aide de code managé d'applications externes, voir « Automatisation d'InfoPath depuis d'autres applications » dans la documentation qui est installée avec Microsoft Visual Studio 2005 Tools pour Microsoft Office System2007.

Informations importantes concernant l'installation

Par défaut, l'option Installation par défaut du programme d'installation d'InfoPath installe des copies des assemblys Microsoft.Office.Interop.InfoPath.SemiTrust et Microsoft.Office.Interop.InfoPath.Xml dans le dossier C:\Program Files\Microsoft Office\Office12. Les assemblys Microsoft.Office.Interop.InfoPath et Microsoft.Office.Interop.InfoPath.Xml sont également installés dans le Global Assembly Cache (GAC) dont vous pouvez consulter le contenu dans le dossier C:\Windows\Assembly.

Si ces assemblys ne sont pas installés, vérifiez que Microsoft Office InfoPath 2007 s'est correctement installé. Si .NET Framework 1.1 Redistributable ou .NET Framework 1.1 Software Development Kit (SDK) est installé avant le démarrage du programme d'installation, l'option Prise en charge de la programmabilité .NET du programme d'installation d'InfoPath est définie sur Exécuter à partir du disque dur pour une Installation par défaut d'InfoPath. Si ces assemblys d'interopérabilité ne sont pas disponibles sur votre ordinateur, vérifiez que .NET Framework 1.1 est installé puis exécutez Ajout/Suppression de programmes depuis le Panneau de configuration et définissez l'option Prise en charge de la programmabilité .NET sur Exécuter à partir du disque dur.

Pour plus d'informations sur le téléchargement de .NET Framework 1.1 Redistributable, voir .NET Framework 1.1 Redistributable (en anglais).

Espace de noms Microsoft.Office.Interop.InfoPath.SemiTrust

Avant la sortie de Microsoft Office InfoPath 2003 Service Pack 1 et du toolkit Microsoft Office InfoPath 2003 pour Visual Studio® .NET, toute la logique de programmation pour les modèles de formulaires InfoPath était créée à l'aide de Microsoft JScript ou Microsoft VBScript écrit dans l'environnement de développement Microsoft Script Editor (MSE) intégré à InfoPath. Les scripts créés dans MSE sont interprétés à l'exécution et accèdent au modèle objet COM de la bibliothèque de liens dynamiques IPEDITOR.dll .

Pour permettre la création de modèles de formulaires qui utilisent des langages avec code managé tels que Visual C# et Visual Basic pour la logique de programmation, une fonctionnalité a été ajoutée pour permettre à InfoPath d'accueillir le CLR (Common Language Runtime) et l'assembly d'interopérabilité Microsoft.Office.Interop.InfoPath.SemiTrust a été créé pour permettre au code managé d'interagir de manière sécurisée avec le modèle objet COM d'InfoPath. Pour plus d'informations sur le modèle de sécurité applicable aux modèles de formulaires InfoPath avec code managé, voir Modèle de sécurité des modèles de formulaires avec code managé.

Bien que le processus de création de code managé pour une tâche donnée dans un modèle de formulaire InfoPath reste très similaire à la tâche de programmation équivalente avec un script, le modèle objet exposé lors de l'affichage de l'espace de noms Microsoft.Office.Interop.InfoPath.SemiTrust dans l'Explorateur d'objets de Microsoft Visual Studio Tools for Applications (VSTA), Visual Studio 2005 avec Microsoft Visual Studio 2005 Tools pour Microsoft Office System2007 ou Visual Studio 2008 avec Visual Studio Tools pour Office paraît plus complexe. Ceci est dû au fait que la technologie d'interopérabilité .NET Framework utilisée pour prendre en charge le modèle objet compatible InfoPath 2003 nécessite un serveur COM pour exposer toutes ses interfaces publiques, ainsi que quelques constructions supplémentaires requises par .NET Framework.

Comment les objets COM sont exposés dans le modèle objet compatible InfoPath 2003

Lorsque vous travaillez avec un serveur COM depuis un langage évolué tel que JScript, VBScript ou Visual Basic (mais pas la version .NET de Visual Basic et Visual C#), le modèle objet exposé est plus simple que les classes et interfaces COM sous-jacentes. Par exemple, dans ce cas, l'objet InfoPath UI expose sept méthodes, dont la méthode Alert pour l'affichage d'une boîte de dialogue de message pour l'utilisateur.

Cependant, les constructions COM sous-jacentes de l'objet UI sont en réalité composées de trois entités : deux interfaces appelées UI et UI2 et une coclasse COM qui implémente les membres de ces deux interfaces. Ces deux versions de l'interface UI sont présentes car l'interface COM requiert que la définition d'une interface reste la même pour maintenir la compatibilité descendante pour les programmes et composants qui appellent une implémentation de cette interface.

Dans ce cas, l'interface UI, définie pour la version initiale d'InfoPath, contient quatre méthodes, dont la méthode Alert. L'interface UI2 peut être considérée comme une deuxième version de l'interface UI. Elle a été définie pour InfoPath Service Pack 1. L'interface UI2 hérite des quatre méthodes de l'interface UI plus trois nouvelles méthodes, dont la méthode Confirm. Bien que vous puissiez écrire une ligne de code, dans un script ou dans du code managé, qui appelle la méthode Confirm à l'aide de XDocument.UI.Confirm, le code sous-jacent appelle en réalité la méthode Confirm de l'interface UI2 de l'implémentation de cette méthode dans la coclasse COM.

Le modèle objet tel qu'il est exposé pour la création de script cache ces détails, mais l'assembly d'interopérabilité expose publiquement à la fois la coclasse et les deux interfaces. Pour le seul objet UI utilisé dans l'environnement de création de scripts MSE, l'espace de noms Microsoft.Office.Interop.InfoPath.SemiTrust expose les trois éléments suivants :

Bien que ces trois interfaces soient exposées dans l'Explorateur d'objets de Visual Studio et qu'elles se trouvent dans la documentation Bibliothèque de classe de l'espace de noms, vous travaillez uniquement avec l'interface de coclasse UIObject, qui implémente l'objet UI, et les membres de l'interface UI2, qui est la version actuelle de l'interface implémentée par l'interface de la coclasse UIObject. Pour accéder comme dans un script à l'interface de la coclasse UIObject depuis son objet parent XDocument, utilisez la propriété d'accès UI. Mis à part quelques exceptions, ceci est le modèle de tous les objets de la version originale d'InfoPath qui ont été mis à jour lors de la sortie d'InfoPath Service Pack 1.

Alors que le modèle est pratiquement le même, la situation est légèrement plus simple pour les nouveaux objets qui ont été ajoutés avec la sortie d'InfoPath Service Pack 1, par exemple l'objet Certificat. Dans ce cas, vous ne devez vous préoccuper que de deux choses : l'interface de la coclasse CertificateObject et les membres de l'interface Certificate, qui est l'interface la plus récente et la seule implémentée par l'interface de la coclasse CertificateObject. De plus, comme pour l'utilisation d'objets COM d'InfoPath depuis un script, la propriété Certificate permet d'accéder à l'objet depuis son parent.

Ce même modèle s'applique aux interfaces des collections, excepté que « Collection » est ajouté au nom de l'interface de coclasse d'une collection au lieu de « Object ». Par exemple, l'interface de coclasse de la collection COM DataAdapters porte le nom DataAdaptersCollection et l'interface qu'elle implémente est l'interface DataAdapters. De la même manière, la propriété DataAdapters de l'objet parent XDocument permet d'accéder à la collection.

Ce modèle présente trois exceptions. Le nom des interfaces de coclasse des objets COM Application et XDocument ne comporte pas la mention « Object ». Leur nom est identique à celui des objets COM correspondants : Application et XDocument. En outre, le nom des interfaces implémentées par les interfaces de coclasse Application et XDocument débute par un trait de soulignement (_) : _Application2 et _XDocument2. La troisième exception est l'objet COM DataObject. L'interface de coclasse de cet objet porte le nom DataSourceObject, mais comme n'importe quel autre objet COM d'InfoPath, l'interface qu'il implémente est l'interface DataObject.

Comment les objets MSXML 5.0 pour Microsoft Office sont exposés au modèle objet compatible InfoPath 2003

Un sous-ensemble des objets et membres du modèle objet fourni par les services MSXML 5.0 (Microsoft XML Core Services) pour Microsoft Office, qui est également un serveur COM, sont inclus dans les interfaces exposées par l'assembly d'interopérabilité Microsoft.Office.Interop.InfoPath.SemiTrust. La raison pour laquelle ceci est nécessaire est que certains des membres du modèle objet COM d'InfoPath s'appuient sur MSXML 5.0 et doivent être en mesure d'accéder à ces membres de manière sécurisée. Les noms des interfaces de l'espace de noms Microsoft.Office.Interop.InfoPath.SemiTrust qui inclut les objets et les membres du modèle objet MSXML 5.0 sont les mêmes que ceux exposés par le serveur COM MSXML 5.0. Dans la plupart des cas, ces noms sont précédés de « IXMLDOM » car ils sont utilisés avec le modèle DOM XML. Par exemple, la propriété DOM de l'interface XDocument, qui est utilisée pour renvoyer une référence au document XML sous-jacent d'un formulaire, renvoie l'interface IXMLDOMDocument qui est incluse dans l'assembly d'interopérabilité Microsoft.Office.Interop.InfoPath.SemiTrust. Vous pouvez appeler et utiliser les membres de l'interface IXMLDOMDocument pratiquement de la même manière que lorsque vous utilisez un script dans un modèle de formulaire sans code managé.

Pour plus d'informations sur l'utilisation des membres du modèle objet MSXML 5.0 (Microsoft XML Core Services) pour Microsoft Office dans des modèles de formulaires avec code managé, voir Utilisation de MSXML5 et de System.Xml avec le modèle objet InfoPath 2003.

Utilisation d'IntelliSense

Pour la majorité du code que vous écrivez dans un modèle de formulaire avec code managé, vous utilisez les variables thisXDocument et thisApplication initialisées dans la méthode _Startup du fichier de classe par défaut FormCode.cs ou FormCode.vb. Vous pouvez utiliser les variables thisXDocument et thisApplication pour accéder aux membres des interfaces de coclasse XDocument et Application. Après avoir tapé le nom d'une variable, suivi d'un point, la fonction IntelliSense de saisie semi-automatique des instructions affiche la liste des membres de l'interface de coclasse correspondante. Vous pouvez continuer ainsi pour accéder au membre du modèle objet avec lequel vous voulez travailler.

L'exemple suivant illustre l'utilisation de la variable thisXDocument pour accéder à la méthode Alert et afficher la version de l'application InfoPath à l'aide de la propriété Version à laquelle la variable thisApplication permet d'accéder.

thisXDocument.UI.Alert(thisApplication.Version);

thisXDocument.UI.Alert(thisApplication.Version)

Utilisation de la documentation de référence de la bibliothèque de classes

L'organisation de l'espace de noms dans la documentation de référence de la Bibliothèque de classes Microsoft.Office.Interop.InfoPath.SemiTrust reflète les relations entre les interfaces de coclasse et les interfaces héritées qu'elles implémentent, tel que décrit dans la section «  Comment les objets COM sont exposés au code managé » plus haut dans cette rubrique.

Bien que l'organisation et l'affectation des noms de la documentation de référence de l'espace de noms Microsoft.Office.Interop.InfoPath.SemiTrust paraissent confuses de prime abord, les rubriques sont en réalité organisées de la même manière que dans la référence du modèle objet InfoPath dans le Guide de référence du développeur d'InfoPath, inclus dans InfoPath. À l'exception des rubriques relatives aux interfaces Application et XDocument, toutes les rubriques des interfaces de coclasse COM correspondent aux rubriques « Object » et « Collection » équivalentes dans la référence sur les scripts d'InfoPath. Par exemple, les rubriques « UIObject Interface » et « WindowsCollection Interface » de la documentation de référence de l'espace de noms Microsoft.Office.Interop.InfoPath.SemiTrust correspondent à un contenu similaire dans les rubriques « UI Object » et « Windows Collection » de la référence sur les scripts du modèle objet InfoPath.

Toutefois, le lien vers les membres de l'interface de coclasse qui suit la description de l'interface en début de rubrique aboutit sur une rubrique vide. Pour afficher la liste des membres implémentés par l'interface de coclasse, vous devez ouvrir la rubrique de la dernière interface héritée par la coclasse, puis ouvrir la table de ses membres. Un lien vers l'interface héritée est proposé au début de la section Remarques de la rubrique consacrée à l'interface de coclasse.

Lorsque vous appuyez sur la touche F1 dans l'Éditeur de code, le comportement est similaire, excepté que le membre pour lequel vous invoquez l'aide est affiché directement car vous travaillez le plus souvent avec des membres d'une interface. Cependant, le fait qu'un membre puisse être implémenté depuis une interface avec version peut paraître confus la première fois que vous y êtes confronté. Par exemple, si vous tapez thisXDocument.UI.Alert puis que vous placez le curseur sur Alert et que vous appuyez sur F1, une rubrique intitulée « UI2.Alert Method » s'affiche. Ceci est dû au fait que la méthode Alert est une implémentation d'un membre de l'interface UI2.

Transmission de paramètres facultatifs à des membres du modèle objet InfoPath

Si un membre du modèle objet compatible InfoPath 2003 contient un paramètre facultatif et que vous ne spécifiez pas de valeur pour ce paramètre, vous devez transmettre le champ Type.Missing de ce paramètre. Si vous ne transmettez pas le champ Type.Missing alors que la valeur est omise, cela provoque une erreur de compilation. Ceci se produit aussi bien pour le code écrit en Visual C# qu'en Visual Basic. Par exemple, la méthode SelectNodes de l'interface ViewObject comprend deux paramètres facultatifs : varEndNode et varViewContext. Une ligne de code dans laquelle les valeurs de ces deux paramètres ne sont pas spécifiées doit ressembler aux exemples suivants.

IXMLDOMNode group1 = 
   thisXDocument.DOM.selectSingleNode("/my:myFields/my:group1");
thisXDocument.View.SelectNodes(group1, Type.Missing, Type.Missing);

Dim group1 As IXMLDOMNode = _
   thisXDocument.DOM.selectSingleNode("/my:myFields/my:group1")
thisXDocument.View.SelectNodes(group1, Type.Missing, Type.Missing)

Conformité avec les spécifications du langage commun

En interne, l'attribut CLSCompliant de toutes les interfaces et tous les membres de l'assembly Microsoft.Office.Interop.InfoPath.SemiTrust est défini sur false. Du fait que la documentation de référence est générée en partie à l'aide de System.Reflection, la chaîne « Interface/méthode/propriété non conforme CLS » est ajoutée à la description de chaque interface et de chaque membre. Cependant, la plupart des interfaces et des membres de l'espace de noms Microsoft.Office.Interop.InfoPath.SemiTrust sont en réalité conformes CLS.

Voir aussi

Concepts

Tâches courantes en matière de développement de modèles de formulaires utilisant le modèle objet InfoPath 2003
Modèle de sécurité des modèles de formulaires avec code managé

Autres ressources

Création de modèles de formulaires avec code managé utilisant le modèle objet InfoPath 2003
Présentation du modèle objet InfoPath 2003