Microsoft Office InfoPath provides developers with a rich development environment for customizing form templates. Form templates can be customized by writing programming code that responds to form and data validation (data validation: The process of testing the accuracy of data; a set of rules you can apply to a control to specify the type and range of data that users can enter.) events, accesses and manipulates the underlying XML document for a form, implements custom data submission and merges, and accesses external data sources. Customizing a form template can also involve altering one of the form template files (form files: A collection of files that are used to implement an InfoPath form. File types can include .html, .xml, .xsd, .xslt, script, and other file types that are necessary to support the functionality of the form.) to meet a specific requirement.
It is important to understand a few key concepts that are involved in programming a form template. These concepts include the InfoPath programming components, declarative and programmatic programming, and supported programming languages and environments.
In this article
InfoPath programmability involves customizing a form template by altering its source files or by writing script to create custom functions that use the InfoPath object model (object model: A hierarchical library of objects and collections that represents the content and functionality of an application. Objects and collections have properties, methods, and events that can be used to manipulate and interact with an application.). The main components of a form template that can involve programmatic interaction are listed in the following table.
||A hierarchical type library composed of collections, objects, properties, methods, and events that give form template developers programmatic control over various aspects of the InfoPath editing environment and access to a form's underlying XML document.
||A combination of XML Schemas (XML Schema: A formal specification, written in XML, that defines the structure of an XML document, including element names and rich data types, which elements can appear in combination, and which attributes are available for each element.), expressions, and scripting code used to validate and constrain the data that users are allowed to enter in a form.
||A set of event handlers (event handler: The function code in an InfoPath form template that responds to a user action or change to the XML data.) that respond to changes to a form's underlying XML document, respond to view (view: A form-specific display setting that can be saved with a form template and applied to form data when the form is being filled out. Users can switch between views to choose the amount of data shown in the form.) switching, implement custom form submission, or respond to the loading of the form's underlying XML document.
||A set of customizable user interface components that includes menus, toolbars, buttons, command bars, and task panes.
||A set of InfoPath-specific controls used to manage and interact with a form's underlying XML document, which includes collections, optional items, and fields. Note that you do not interact with these editing controls directly, but rather through the form's underlying XML document to which the controls are bound (bind: To connect a control to a field or group in the data source so that data entered into the control is saved. When a control is unbound, it is not connected to a field or group, and so data entered into the control will not be saved.).
||A combination of event handlers, object model calls, and form definition (.xsf) file (form definition file: An XML file with an .xsf extension that contains information about all other files and components used within a form, including user interface customizations, XML Schemas, views, business logic, events, and deployment settings.) entries that are used to handle errors in a form.
||A set of security levels that restrict access to the InfoPath object model and system resources.
||A set of predefined functions that can be used to implement custom posting and submission functionality for a form.
||A set of custom scripting files that contain programming code used to implement specific editing behavior, data validation, event handlers, and control of data flow. Business logic can also include accessing of external Component Object Model (COM) (Component Object Model (COM): A specification developed by Microsoft for building software components that can be assembled into programs or can add functionality to existing programs running on Microsoft Windows operating systems.) components.
||Integration of other Microsoft Office programs such as Microsoft Office Excel or Microsoft Office Outlook. Integration may also involve the use of back-end servers such as Microsoft SQL Server, Microsoft Windows SharePoint Services, or XML Web services.
Top of Page
Declarative and programmatic development
When you alter form template files, you customize the form template declaratively — that is, you open the files in a standard text editor and manually change the elements, attributes, and values of the files. When you alter a form template programmatically, you write programming code by using a scripting language or a managed code language, in conjunction with the InfoPath object model and, in some cases, COM components, to extend and enhance the behavior of a form template.
The following are some of the ways that you can customize a form template declaratively:
The following are some of the ways that you can customize a form template programmatically:
For detailed information about the InfoPath programming components and customizing a form template either declaratively or programmatically, see the InfoPath Developer's Reference, which is installed with InfoPath and can be accessed from InfoPath Help in design mode.
Top of Page
Programming languages and environments
Like other Microsoft Office programs, InfoPath supports several programming environments and programming languages that developers can use to automate and extend Office programs. However, while most Office programs use Microsoft Visual Basic for Applications (VBA) (Visual Basic for Applications (VBA): A macro-language version of Microsoft Visual Basic that is used to program Windows applications and is included with several Microsoft applications.) as their primary programming language, InfoPath uses two scripting languages — Microsoft JScript (JScript: An interpreted, object-based scripting language that borrows from C, C++, and Java. It is the Microsoft implementation of the ECMA 262 language specification.) and Microsoft Visual Basic Scripting Edition (VBScript) (Visual Basic Scripting Edition (VBScript): An interpreted, object-based scripting language that is a subset of the Microsoft Visual Basic programming language.), and two managed-code languages, Microsoft Visual C# and Microsoft Visual Basic. In addition, the programming environment that is used when writing script in InfoPath is the Microsoft Script Editor (MSE) (Microsoft Script Editor: Used to add text, edit HTML tags, and edit any Microsoft Visual Basic Scripting Edition (VBScript) code in a data access page. You can also view your page in the Script Editor as it would appear in a Web browser.), not the Visual Basic Editor (Visual Basic Editor: An environment in which you write new and edit existing Visual Basic for Applications code and procedures. The Visual Basic Editor contains a complete debugging toolset for finding syntax, run-time, and logic problems in your code.). Finally, the environment included for writing managed code is Microsoft Visual Studio 2005 Tools for Applications (VSTA), which can be installed when the Microsoft .NET Framework 2.0 and Microsoft Core XML Services 6.0 are present.
Top of Page