InfoPath 2003-kompatible Objektmodelle

Artikel
06/03/2010

Microsoft InfoPath 2010 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, in denen die Programmiersprachen Visual C# und Visual Basic mit verwaltetem Code verwendet werden, werden vom InfoPath-Setupprogramm drei Interop-Assemblys installiert. Interop-Assemblys sind .NET-Assemblys, die als Verbindung zwischen verwaltetem und nicht verwaltetem Code dienen, indem sie COM-Objektmember entsprechenden verwalteten .NET-Membern zuordnen.

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 Assemblys Microsoft.Office.Interop.InfoPath und Microsoft.Office.Interop.InfoPath.Xml finden Sie in der Dokumentation zu den Namespaces Microsoft.Office.Interop.InfoPath und Microsoft.Office.Interop.InfoPath.Xml.

Wichtige Informationen zur Installation

Standardmäßig werden mit der Installationsoption Standard des InfoPath-Setupprogramms Kopien der Assemblys Microsoft.Office.Interop.InfoPath.SemiTrust und Microsoft.Office.Interop.InfoPath.Xml im Ordner C:\Programme\Microsoft Office\Office14 installiert. Die Assemblys Microsoft.Office.Interop.InfoPath und Microsoft.Office.Interop.InfoPath.Xml werden außerdem im globalen Assemblycache (Global Assembly Cache, GAC) installiert, dessen Inhalt im Ordner C:\Windows\Assembly angezeigt werden kann.

Wenn diese Assemblys nicht installiert werden, sollten Sie sich vergewissern, dass Microsoft InfoPath 2010 richtig installiert wurde. Solange .NET Framework 2.0 oder höher vor dem Ausführen des Setups installiert war, wird die Option .NET-Programmierunterstützung im InfoPath-Setupprogramm bei einer Standardinstallation von InfoPath auf Von "Arbeitsplatz" ausführen festgelegt. Wenn diese Interop-Assembly auf dem Computer nicht verfügbar sind, müssen Sie sich vergewissern, dass .NET Framework 2.0 oder höher 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 Herunterladen von .NET Framework 2.0 Redistributable finden Sie unter .NET Framework 2.0 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. Ein in MSE geschriebenes Skript wird zur Laufzeit interpretiert und greift auf das COM-Objektmodell zu, das von der Dynamic Link Library IPEDITOR.dll verfügbar gemacht wird.

Zur Unterstützung der Erstellung von Formularvorlagen, in denen für die Programmierlogik Sprachen mit verwaltetem Code wie beispielsweise Visual C# und Visual Basic verwendet werden, 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 verfügbar gemachten COM-Objektmodell sicher zusammenarbeiten kann. Weitere Informationen zu dem Sicherheitsmodell, das auf InfoPath-Formularvorlagen 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 die gleiche Programmieraufgabe Skript geschrieben wird, jedoch hat das InfoPath 2003-kompatible Objektmodell, das beim Anzeigen des Microsoft.Office.Interop.InfoPath.SemiTrust-Namespace über den Objektbrowser in Microsoft Visual Studio Tools for Applications verfügbar gemacht wird, einen erheblich komplexeren Aufbau. Das liegt daran, dass die Interoperabilitätstechnologie von .NET Framework, die für die Unterstützung des InfoPath 2003-kompatiblen Objektmodells verwendet wird, einen COM-Server erfordert, damit alle öffentlichen Schnittstellen verfügbar gemacht werden können. Weiterhin sind einige zusätzliche Konstrukte für .NET Framework selbst erforderlich.

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:

UI-Schnittstelle
UI2-Schnittstelle
UIObject-Coklassen-Schnittstelle

Auch wenn diese Schnittstellen alle drei im Objektbrowser verfügbar gemacht werden und in der Dokumentation zur Klassenbibliothek des Namespace enthalten sind, arbeiten Sie nur mit der UIObject-Co-Klassenschnittstelle, durch die das UI-Objekt implementiert wird, und mit den Membern der UI2-Schnittstelle. Bei dieser handelt es sich um die aktuellste Version der Schnittstelle, die von der UIObject-Co-Klassenschnittstelle implementiert wird. Zum Zugreifen auf die UIObject-Co-Klassenschnittstelle über das übergeordnete XDocument-Objekt verwenden Sie wie im 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

Eine Teilmenge der Objekte und Member des von Microsoft XML Core Services (MSXML) bereitgestellten Objektmodells, das auch ein COM-Server ist, wird von den durch die Microsoft.Office.Interop.InfoPath.SemiTrust-Interop-Assembly verfügbar gemachten Schnittstellen eingebunden. Der Grund hierfür ist, dass einige der Member des COM-Objektmodells von InfoPath von MSXML abhängig sind und auf diese Member sicher zugreifen müssen. Die Namen der Schnittstellen im Microsoft.Office.Interop.InfoPath.SemiTrust-Namespace, die die Objekte und Member des MSXML-Objektmodells einbinden, sind mit den durch den MSXML-COM-Server verfügbar gemachten Namen identisch. In den meisten Fällen wird diesen Namen "IXMLDOM" vorangestellt, da sie für XML-DOM (Document Object Model) verwendet werden. So gibt beispielsweise die DOM-Eigenschaft der XDocument-Schnittstelle, die zum Zurückgeben eines Verweises auf das einem Formular zugrunde liegende XML-Dokument verwendet wird, die IXMLDOMDocument-Schnittstelle zurück, die von der Microsoft.Office.Interop.InfoPath.SemiTrust-Interop-Assembly eingebunden ist. Beim Aufrufen und Verwenden der Member der IXMLDOMDocument-Schnittstelle gehen Sie grundsätzlich genau so vor wie beim Verwenden von Skript in Formularvorlagen, in denen kein verwalteter Code verwendet wird.

Weitere Informationen zum Verwenden von Membern von Microsoft XML Core Services (MSXML) für das Microsoft Office-Objektmodell in Formularvorlagen mit verwaltetem Code finden Sie unter Arbeiten mit MSXML und System.Xml mit dem InfoPath 2003-Objektmodell.

Verwenden von IntelliSense

Beim meisten Code, den Sie in Formularvorlage mit verwaltetem Code für das InfoPath 2003-kompatible Objektmodell schreiben, verwenden Sie die Variablen thisXDocument und thisApplication, die in der _Startup-Methode der Standardklassendatei FormCode.cs oder FormCode.vb verwendet werden. Sie können die Variablen thisXDocument und thisApplication verwenden, um auf die Member der Co-Klassenschnittstellen XDocument und Application zuzugreifen. Wenn Sie den Namen einer der Variablen gefolgt von einem Punkt eingegeben haben, zeigt die Anweisungsvervollständigung von IntelliSense die Listenmember der entsprechenden Co-Klassenschnittstelle 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 InfoPath 2003-kompatibles Objektmodellmember einen optionalen Parameter enthält und Sie keinen Wert für diesen Parameter angeben, müssen Sie stattdessen das Type.Missing-Feld für diesen Parameter übergeben. Wenn das Type.Missing-Feld nicht angegeben wird und ein tatsächlicher Wert ausgelassen wird, führt dies zu einem Buildfehler. Dies trifft sowohl auf in Visual C# als auch auf in Visual Basic geschriebenen Code zu. Beispielsweise enthält die SelectNodes-Methode der ViewObject-Schnittstelle 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.