InfoPath 2003-kompatible Objektmodelle
Microsoft Office InfoPath 2007 ist als COM-Anwendung (Component Object Model) geschrieben, und die Programmierschnittstellen dieses Programms sind sowohl für das Skript für externe Automatisierung als auch für Formularvorlagen als COM-Schnittstellen verfügbar. Als Unterstützung für die Erstellung von InfoPath-Projektmappen, die die Programmiersprachen Visual C# und Visual Basic mit verwaltetem Code verwenden, werden vom InfoPath-Installationsprogramm drei Interop-Assemblys installiert. Interop-Assemblys sind .NET-Assemblys, die als Verbindung zwischen verwaltetem und nicht verwaltetem Code dienen, indem sie COM-Objektmember entsprechende verwaltete .NET-Member zuweisen.
Die Dateien für die von InfoPath installierten drei Interop-Assemblys lauten:
Microsoft.Office.Interop.InfoPath.dll
Microsoft.Office.Interop.InfoPath.SemiTrust.dll
Microsoft.Office.Interop.InfoPath.Xml.dll
In diesem Thema wird das Objektmodell erläutert, das über die Microsoft.Office.Interop.InfoPath.SemiTrust-Interop-Assembly offen gelegt wird, die ausschließlich zum Schreiben und Ausführen von Geschäftslogik mit verwaltetem Code innerhalb von InfoPath-Formularvorlagen (XSN) verwendet wird.
Weitere Informationen zu den Microsoft.Office.Interop.InfoPath- und Microsoft.Office.Interop.InfoPath.Xml-Assemblys, die ausschließlich zum Automatisieren der InfoPath-Anwendung mithilfe von verwaltetem Code von externen Anwendungen verwendet werden, finden Sie in der mit Microsoft Visual Studio 2005 Tools für 2007 Microsoft Office System installierten Dokumentation unter "Automatisieren von InfoPath aus anderen Anwendungen".
Wichtige Informationen zur Installation
Standardmäßig werden mit der Installationsoption Standard des InfoPath-Setupprogramms Kopien der Microsoft.Office.Interop.InfoPath.SemiTrust- und Microsoft.Office.Interop.InfoPath.Xml-Assemblys im Ordner "C:\Programme\Microsoft Office\Office12" installiert. Die Microsoft.Office.Interop.InfoPath- und Microsoft.Office.Interop.InfoPath.Xml-Assemblys werden außerdem im globalen Assemblycache (Global Assembly Cache, GAC) installiert, dessen Inhalte über den Ordner "C:\Windows\Assembly" überprüft werden können.
Wenn diese Assemblys nicht installiert werden, sollten Sie bestätigen, dass Microsoft Office InfoPath 2007 richtig installiert wurde. So lange .NET Framework 1.1 Redistributable oder .NET Framework 1.1 Software Development Kit (SDK) vor dem Ausführen von Setup installiert wurde, wird die Option .NET-Programmierunterstützung des InfoPath-Setupprogramms bei der Installation Standard von InfoPath auf Von Arbeitsplatz ausführenfestgelegt. Wenn diese Interop-Assemblys nicht auf dem Computer verfügbar sind, müssen Sie bestätigen, dass .NET Framework 1.1 installiert ist, und dann in der Systemsteuerung die Option Software ausführen und anschließend die Option .NET-Programmierunterstützung auf Von Arbeitsplatz ausführen festlegen.
Weitere Informationen zum Download von .NET Framework 1.1 Redistributable finden Sie unter .NET Framework 1.1 Redistributable.
Microsoft.Office.Interop.InfoPath.SemiTrust-Namespace
Vor der Veröffentlichung von Microsoft Office InfoPath 2003 Service Pack 1 und Microsoft Office InfoPath 2003 Toolkit für Visual Studio® .NET wurde die gesamte Programmierlogik für InfoPath-Formularvorlagen mithilfe von Microsoft JScript oder Microsoft VBScript erstellt, das in der Microsoft Script Editor-Entwicklungsumgebung (MSE) geschrieben wurde und in InfoPath integriert ist. Ein in MSE geschriebenes Skript wird zur Laufzeit interpretiert und greift auf das COM-Objektmodell zu, das von der Dynamic Link Library "IPEDITOR.dll" offen gelegt wird.
Zur Unterstützung der Erstellung von Formularvorlagen, die für die Programmierlogik Sprachen mit verwaltetem Code wie beispielsweise Visual C# und Visual Basic verwenden, wurde InfoPath Funktionalität zum Hosten der Common Language Runtime (CLR) hinzugefügt. Außerdem wurde die Microsoft.Office.Interop.InfoPath.SemiTrust-Interop-Assembly erstellt, sodass verwalteter Code mit dem von InfoPath offen gelegten COM-Objektmodell sicher zusammenarbeiten konnte. Weitere Informationen zum Sicherheitsmodell, das auf die InfoPath-Formularvorlage mit verwaltetem Code angewendet wird, finden Sie unter Informationen zum Sicherheitsmodell für Formularvorlagen mit verwaltetem Code.
Das Schreiben von verwaltetem Code für eine bestimmte Aufgabe in einer InfoPath-Formularvorlage ist zwar dem Prozess sehr ähnlich, bei dem für dieselbe Programmieraufgabe Skript geschrieben wird, das Objektmodell, das beim Anzeigen des Microsoft.Office.Interop.InfoPath.SemiTrust-Namespace über den Objektbrowser in Microsoft Visual Studio Tools für Anwendungen (VSTA), Visual Studio 2005 mit Microsoft Visual Studio 2005 Tools für 2007 Microsoft Office System oder Visual Studio 2008 mit Visual Studio Tools für Office offen gelegt wird, hat jedoch einen komplexeren Aufbau. Dies ist der Fall, da die Interoperabilitätstechnologie von .NET Framework, die zum Unterstützen des mit InfoPath 2003 kompatiblen Objektmodells verwendet wird, einen COM-Server erfordert, damit alle seine öffentlichen Schnittstellen offen gelegt werden können. Weiterhin sind einige zusätzliche Konstrukte erforderlich, die .NET Framework benötigt.
Verfügbarmachen von COM-Objekten für das mit InfoPath 2003 kompatible Objektmodell
Bei der systemeigenen Arbeit mit einem COM-Server mit Programmiersprachen hoher Ebene, beispielsweise JScript, VBScript oder Visual Basic (jedoch nicht die .NET-Versionen von Visual Basic und Visual C#), ist das offen gelegte Objektmodell einfacher als die zugrunde liegenden COM-Klassen und Schnittstellen. So legt das UI-Objekt von InfoPath bei der Arbeit mit diesen Sprachen eine Gruppe mit sieben Methoden offen, beispielsweise die Alert-Methode, um ein Meldungsfeld für Benutzer anzuzeigen.
Die zugrunde liegenden COM-Konstrukte, die das UI-Objekt unterstützen, bestehen jedoch aus drei Entitäten: Zwei Schnittstellen mit Namen UI und UI2 sowie einer COM-Coklasse, die die Member dieser beiden Schnittstellen implementiert. Es gibt zwei Versionen der UI-Schnittstelle, da das COM-Framework die Definition einer fest bestehenden Schnittstelle benötigt, um Rückwärtskompatibilität für Programme und Komponenten beizubehalten, die eine Implementierung dieser Schnittstelle aufrufen.
In diesem Fall stellt die UI-Schnittstelle, die für die erste Version von InfoPath definiert wurde, vier Methoden bereit, einschließlich der Alert-Methode. Die UI2-Schnittstelle kann als zweite Version der UI-Schnittstelle betrachtet werden, und sie wurde für InfoPath Service Pack 1 definiert. Die UI2-Schnittstelle erbt die vier Methoden der ursprünglichen UI-Schnittstelle und fügt drei neue Methoden hinzu, beispielsweise die Confirm-Methode. Sie können zwar eine Codezeile entweder in Skript oder verwaltetem Code schreiben, das bzw. der die Confirm-Methode mit XDocument.UI.Confirm aufruft, der zugrunde liegende Code ruft jedoch tatsächlich die Confirm-Methode der UI2-Schnittstelle der Implementierung der Methode in der COM-Coklasse auf.
Wenn das Objektmodell für das Scripting offen gelegt wird, blendet es diese Details zwar aus, die Interop-Assembly, die für die Arbeit mit einem COM-Server für den verwalteten Code erforderlich ist, legt die Coklasse und beide Schnittstellen jedoch öffentlich offen. Für das einzelne, in der MSE-Scriptingumgebung verwendete UI-Objekt legt der Microsoft.Office.Interop.InfoPath.SemiTrust-Namespace die folgenden drei Elemente offen:
Auch wenn diese Schnittstellen alle drei im Objektbrowser von Visual Studio offen gelegt werden und in der Dokumentation zur Klassenbibliothek des Namespace enthalten sind, arbeiten Sie nur mit der UIObject-Coklassen-Schnittstelle, die das UI-Objekt implementiert, sowie mit den Membern der UI2-Schnittstelle, die die aktuellste Version der Schnittstelle darstellt, die von der UIObject-Coklassen-Schnittstelle implementiert wird. Zum Zugreifen auf die UIObject-Coklassen-Schnittstelle von ihrem übergeordneten XDocument-Objekt aus verwenden Sie wie bei dem Skript die UI-Accessoreigenschaft. Abgesehen von einigen beachtenswerten Ausnahmen ist dies das Muster für alle Objekte der ursprünglichen InfoPath-Version, die bei Veröffentlichung von InfoPath Service Pack 1 aktualisiert wurden.
Das Muster ist zwar grundsätzlich dasselbe, dennoch ist die Situation bei völlig neuen Objekten etwas einfacher, die in InfoPath Service Pack 1 hinzugefügt wurden, beispielsweise demCertificate-Objekt. In diesem Fall müssen nur zwei Elemente besonders beachtet werden: die CertificateObject-Coklassen-Schnittstelle und die Member der Certificate-Schnittstelle, die die aktuellste und einzige Schnittstelle ist, die von der CertificateObject-Coklassen-Schnittstelle implementiert wird. Ebenso wie InfoPath-COM-Objekte von dem Skript verwendet werden, wird die Certificate-Accessoreigenschaft zum Zugreifen auf das Objekt von seinem übergeordneten Objekt aus verwendet.
Dasselbe Muster wird auch auf die Schnittstellen für Auflistungen angewendet, wobei an die Coklassen-Schnittstelle für eine Auflistung "Collection" an den Namen angefügt ist anstelle von "Object". So hat beispielsweise die Coklassen-Schnittstelle für die COM-DataAdapters-Auflistung den Namen DataAdaptersCollection und die Schnittstelle, die sie implementiert, ist die DataAdapters-Schnittstelle. Entsprechend wird die DataAdapters-Accessoreigenschaft des übergeordneten XDocument-Objekts zum Zugreifen auf die Auflistung verwendet.
Zu diesem Benennungsmuster gibt es drei Ausnahmen. Bei der Coklassen-Schnittstelle für das COM-Application-Objekt und das XDocument-Objekt ist kein "Object" an den Namen angefügt. Diese Namen stimmen mit ihren entsprechenden COM-Objekten überein: Application und XDocument. Darüber hinaus ist den Namen der von der Application-Coklassen-Schnittstelle und der XDocument-Coklassen-Schnittstelle implementierten Schnittstellen jeweils ein Unterstrich (_) vorangestellt: _Application2 und _XDocument2. Die dritte Ausnahme ist das COM-DataObject-Objekt. Die Coklassen-Schnittstelle für dieses Objekt hat den Namen DataSourceObject. Dennoch ist wie bei anderen InfoPath-COM-Objekten auch die Schnittstelle, die es implementiert, die DataObject-Schnittstelle.
Verfügbarmachen von Microsoft XML Core Services (MSXML) 5.0 für Microsoft Office-Objekte für das mit InfoPath 2003 kompatible Objektmodell
Ein Subset der Objekte und Member des von Microsoft XML Core Services (MSXML) 5.0 für Microsoft Office bereitgestellten Objektmodells, das auch ein COM-Server ist, wird von den von der Microsoft.Office.Interop.InfoPath.SemiTrust interop-Assembly offen gelegten Schnittstellen eingebunden. Der Grund hierfür ist, dass einige der Member des InfoPath-COM-Objektmodells von MSXML 5.0 abhängig sind und auf diese Member sicher zugreifen müssen. Die Namen der Schnittstellen im Microsoft.Office.Interop.InfoPath.SemiTrust-Namespace, der die Objekte und Member des MSXML 5.0-Objektmodells einbinden, sind dieselben wie die Namen, die von dem MSXML 5.0-COM-Server eingebunden werden. In den meisten Fällen ist diesen Namen "IXMLDOM" vorangestellt, da sie für die Arbeit mit dem XML-DOM (Document Object Model) verwendet werden. So gibt beispielsweise die DOM-Eigenschaft der XDocument-Schnittstelle, die zum Zurückgeben des zugrunde liegenden XML-Dokuments eines Formulars verwendet wird, die IXMLDOMDocument-Schnittstelle zurück, die von der Microsoft.Office.Interop.InfoPath.SemiTrust-Interop-Assembly eingebunden ist. Sie rufen die Member der IXMLDOMDocument-Schnittstelle grundsätzlich ebenso auf und verwenden sie genau so, wie wenn Sie Skript in Formularvorlagen verwenden, bei denen kein verwalteter Code verwendet wird.
Weitere Informationen zum Verwenden von Membern von Microsoft XML Core Services (MSXML) 5.0 für das Microsoft Office-Objektmodell in Formularvorlagen mit verwaltetem Code finden Sie unter Arbeiten mit MSXML5 und System.Xml mit dem InfoPath 2003-Objektmodell.
Verwenden von IntelliSense
Bei dem meisten Code, den Sie in einer Formularvorlage mit verwaltetem Code schreiben, verwenden Sie die Variablen thisXDocument und thisApplication, die in der _Startup-Methode der Standardklassendatei "FormCode.cs" oder "FormCode.vb" initialisiert werden. Sie können die Variablen thisXDocument und thisApplication zum Zugreifen auf die Member der XDocument- und der Application-Coklassen-Schnittstellen verwenden. Wenn Sie den Namen einer der Variablen gefolgt von einem Punkt eingegeben haben, zeigt die Anweisungsvervollständigung von IntelliSense die Listenmember der entsprechenden Coklassen-Schnittstelle an. Sie können auf diese Weise auf das Objektmodellmember zugreifen, mit dem Sie arbeiten möchten.
Nachfolgend finden Sie ein einfaches Beispiel, bei dem die thisXDocument-Variable zum Zugreifen auf die Alert-Methode verwendet wird, um die Version der InfoPath-Anwendung anzuzeigen, indem die Version-Eigenschaft verwendet wird, auf die von der thisApplication-Variable zugegriffen wird.
thisXDocument.UI.Alert(thisApplication.Version);
thisXDocument.UI.Alert(thisApplication.Version)
Verwenden der Referenzdokumentation der Klassenbibliothek
Die Organisation der Referenzdokumentation des Microsoft.Office.Interop.InfoPath.SemiTrust-Namespace spiegelt die Beziehungen zwischen Coklassen-Schnittstellen und den geerbten Schnittstellen wider, die sie implementieren. Dies wird weiter oben in diesem Thema im Abschnitt "Verfügbarmachen von COM-Objekten für verwalteten Code" erläutert.
Auch wenn die Organisation und Benennung der Referenzdokumentation des Microsoft.Office.Interop.InfoPath.SemiTrust-Namespace zunächst etwas verwirrend erscheinen mag, sind die Themen grundsätzlich genau so organisiert wie die Referenz zum InfoPath-Objektmodell, die Bestandteil der InfoPath Developer-Referenz ist und in InfoPath enthalten ist. Mit Ausnahme der Themen für die Schnittstellen Application und XDocument sind alle Themen zur COM-Coklassen-Schnittstelle den entsprechenden Themen "Object" und "Collection" der InfoPath-Skriptreferenz zugeordnet. So entsprechen beispielsweise die Themen "UIObject-Schnittstelle" und "WindowsCollection-Schnittstelle" der Referenzdokumentation für den Microsoft.Office.Interop.InfoPath.SemiTrust-Namespace demselben Inhalt der Themen "UI-Objekt" und "Windows-Auflistung" der Skriptreferenz zur Referenz für das InfoPath-Objektmodell.
Der Link zu den Membern der Coklassen-Schnittstelle nach der Beschreibung der Schnittstelle am Anfang des Themas verweist allerdings auf ein leeres Thema. Sie müssen zum Anzeigen der Liste mit Membern, die von der Coklassen-Schnittstelle implementiert werden, das Thema für die aktuellste Schnittstelle öffnen, die von der Coklasse geerbt wird, und dann die Tabelle ihrer Member öffnen. Sie finden einen Link zu der geerbten Schnittstelle am Anfang des Themas zur Coklassen-Schnittstelle im Abschnitt "Hinweise".
Wenn Sie im Code-Editor auf F1 drücken, ist das Verhalten ähnlich, abgesehen davon, dass der Member, für den Sie die Hilfe mithilfe von F1 aufrufen, direkt angezeigt wird, da Sie mit großer Wahrscheinlichkeit mit Membern einer Schnittstelle arbeiten werden. Dennoch kann die Tatsache, dass ein Member von einer versionsspezifischen Schnittstelle implementiert werden kann, zunächst verwirrend erscheinen. Wenn Sie beispielsweise thisXDocument.UI.Alert eingeben, den Cursor auf Alert platzieren und F1 drücken, wird ein Thema mit Namen "UI2.Alert-Methode" angezeigt. Dies ist der Fall, da die Alert-Methode eine Implementierung eines Members der UI2-Schnittstelle ist.
Übergeben optionaler Parameter an InfoPath-Objektmodellmember
Wenn ein mit InfoPath 2003 kompatibles Objektmodellmember einen optionalen Parameter enthält und Sie keinen Wert für diesen Parameter angeben, müssen Sie stattdessen das Feld Type.Missing für diesen Parameter übergeben. Wird das Feld Type.Missing nicht übergeben, wenn ein tatsächlicher Wert ausgelassen wird, führt dies zu einem Buildfehler. Dies trifft auf sowohl in Visual C# als auch in Visual Basic geschriebenen Code zu. So enthält die SelectNodes-Methode der ViewObject-Schnittstelle beispielsweise zwei optionale Parameter: varEndNode und varViewContext. Eine Codezeile, in der keine tatsächlichen Werte für diese optionalen Parameter angegeben sind, sollte wie in den folgenden Beispielen dargestellt aussehen.
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)
Informationen zur CLS-(Common Language Specification-)Kompatibilität
Bei jeder Schnittstelle und jedem Member in der Microsoft.Office.Interop.InfoPath.SemiTrust-Assembly ist das entsprechende CLSCompliant-Attribut intern auf false festgelegt. Da die Referenzdokumentation teilweise mithilfe von System.Reflection generiert wird, ist an die Beschreibung jeder Schnittstelle und jedes Members der Satz "Diese Schnittstelle/Methode/Eigenschaft ist nicht CLS-kompatibel" angefügt. Die meisten Schnittstellen und Member des Microsoft.Office.Interop.InfoPath.SemiTrust-Namespace sind jedoch tatsächlich CLS-kompatibel.
Siehe auch
Konzepte
Allgemeine Aufgaben für das Entwickeln der Formularvorlagen mithilfe des InfoPath 2003-Objektmodells
Informationen zum Sicherheitsmodell für Formularvorlagen mit verwaltetem Code
Sonstige Ressourcen
Erstellen von Formularvorlagen mit verwaltetem Code mit dem InfoPath 2003-Objektmodell
Grundlegendes zum InfoPath 2003-Objektmodell