About the InfoPath object model
The Microsoft Office InfoPath 2003 object model is a COM-based object model that can be used to interact with InfoPath forms and their underlying XML documents. It is similar to other Microsoft Office application object models in that it implements interfaces for collections, objects, properties, methods, and events. However, the InfoPath object model is primarily used in scripting code, using the Microsoft Script Editor (MSE) that is built into InfoPath.
Note Unlike other Office applications that support complete application automation, the InfoPath object model supports automation of only certain features of the run-time editing environment.
The following sections discuss the InfoPath functional areas that the object model represents, the locations from which the object model can be accessed, and the levels of object model security.
The InfoPath object model is divided into a few main functional areas, with each area responsible for managing different aspects of an InfoPath form:
- Application The root-level object of the object model hierarchy that serves as the entry point to most of the object model members
- ExternalApplication An object that is used to provide limited automation of an InfoPath form
- XDocuments A collection of a form's XDocument objects
- Windows A collection of a form's Window objects
- View An object that represents a given view of a form
Within these higher-level objects are an assortment of lower-level objects that provide more granular information and control over an InfoPath form.
The InfoPath object model is manipulated through scripting code. Scripting code can be used in a variety of ways within a form, including the following:
- Form logic Script that is contained in a form's associated script files. Often this is scripting code that is used within an InfoPath form or data validation event handler.
- Task pane Script that is contained in the programming code for a custom task pane.
- Dialog box Script that is contained in the programming code for a custom dialog box.
- View Script that is contained in the XSL Transformation (XSLT) code for a view.
The InfoPath object model implements three distinct levels of security. These security levels determine how and where a particular object model member can be used. There are three security levels in the InfoPath object model:
- 0: Can be accessed without restrictions.
- 1: Reserved for future use
- 2: Can be accessed only by forms running in the same domain as the currently open form, or by forms that have been granted cross-domain permissions.
- 3: Can be accessed only by fully trusted forms.
Note Each of the InfoPath object model language reference topics contains a security section that details the security level that applies to that object model member.
Viewing Service Pack 1 object model changes from the Object Browser
In Microsoft Office 2003 Editions Service Pack 1, the InfoPath object model was changed to add new objects and collections, and to add new functionality to some preexisting objects and collections. When viewed from the Object Browser in the Microsoft Script Editor, most new objects and collections are displayed with the string "Object" or "Collection" appended to their names. For example, in the Object Browser, the new Math object is displayed as MathObject, and the new DataAdapters collection is displayed as the DataAdaptersCollection. Additionally, most preexisting objects and collections that were changed are displayed as an object that has the string "Object" or "Collection" appended to its name along with an interface without the appended string. For example, the UI object that was changed in Service Pack 1 is displayed as the UIObject object along with the UI interface in the Object Browser. Regardless of how these new and changed objects are displayed in the Object Browser, your code should always call them using the name without "Object" or "Collection" appended to it.