Export (0) Print
Expand All

Introducing InfoPath Development [InfoPath 2003 SDK Documentation]

Office 2003

Microsoft Office InfoPath, the newest addition to the Microsoft Office System, supports a robust programming model and development environment. This article introduces InfoPath development and includes an overview of the main development components, information about the development environment, an overview of the object model and form definition file, and a discussion of the key development areas.

Introduction
Overview of InfoPath Development Components
Overview of the Programming Environment
Overview of the InfoPath Object Model
Overview of the InfoPath Form Definition File
Key Areas of InfoPath Development
Developing a Simple Form
Conclusion

Introduction

By now you may have heard about Microsoft's newest addition to the Office System: Microsoft Office InfoPath is the desktop application that can be used to design rich, dynamic forms based on Extensible Markup Language (XML). What you may not have heard is that just like many of the other Office applications, InfoPath supports a robust programming model and development environment. This article introduces InfoPath development and includes an overview of the main development components, information about the development environment, an overview of the object model and form definition file, and a discussion of the key development areas.

Overview of InfoPath Development Components

When developing a custom solution using an Office application, you will most often be working with development components such as a programming environment, an object model, and assorted events that occur as the application is being used. Working with InfoPath is similar in this regard; however, InfoPath also has a few unique development components.

The Programming Environment

Most Office applications use Microsoft Visual Basic for Applications (VBA) as their primary integrated development environment, but InfoPath does not. Instead, it uses the Microsoft Script Editor (MSE) as its primary programming environment. This means that when you develop an InfoPath form, you will not use Visual Basic as the programming language; you will use a scripting language instead. The scripting languages that InfoPath supports are Microsoft JScript and Microsoft VBScript. By using these scripting languages, you can extend and customize the functionality of your InfoPath forms. For more information on the Microsoft Script Editor, see Overview of the Programming Environment later in this article.

Note  If you have Microsoft Visual Studio .NET 2003, you can use the Microsoft Office InfoPath 2003 Toolkit for Visual Studio .NET to create InfoPath projects using managed code. For more information on using Visual Studio .NET to create InfoPath projects, see the documentation installed with the InfoPath 2003 Toolkit for Visual Studio .NET. For information on how to download the InfoPath 2003 Toolkit for Visual Studio .NET, see the InfoPath Developer Page on Office Developer Center.

The Object Model

Like other Office applications, InfoPath includes a robust object model that can be used to interact with the application, its forms, and the data that the forms contain. The InfoPath object model also contains properties that are used to return references to the XML Document Object Model (DOM). The DOM interacts with the XML documents (or files) that are used in an InfoPath form, including the XML data that an InfoPath form produces.

The top-level object of the InfoPath object model is the Application object, through which you can gain access to the other objects that the object model contains. Other key objects of the InfoPath object model include the Window object, which is used to access various components of the InfoPath user interface, and the XDocument object, which is used to access various components of a form and its underlying XML document.

A major difference between the InfoPath object model and other Office application object models is that the InfoPath object model does not support full automation. You cannot use the InfoPath object model to programmatically create an InfoPath form. However, the InfoPath object model does provide the ExternalApplication object, which can be used to perform a limited set of operations within InfoPath such as opening, registering, and closing a form.

Note  The InfoPath object model is discussed in more detail later in this article.

The Form Definition File

Unique to InfoPath is the form definition (.xsf) file. The .xsf file is an XML file with an .xsf extension that serves as the manifest of an InfoPath form. The manifest.xsf file can be considered the glue that holds together information about how the form is constructed, used, and deployed. The .xsf file is automatically created by InfoPath when you design a form, and it is packaged with the other form files into an .xsn file.

In general, the information that the .xsf files contains should only be created by InfoPath; however, you can make some modifications directly to the .xsf file to extend the functionality of a form. Because the format of the .xsf file is standard XML, it can be directly modified by any type of standard text editor such as Microsoft Notepad.

Note  The InfoPath form definition file is discussed in more detail later in this article.

The Form Files

An InfoPath form is implemented by using a variety of different file types, collectively known as the form files. The form files include all of the files used to construct an InfoPath form template, which is an InfoPath file with an .xsn extension. The form files include the .xsf file, XML Schemas, XML templates, and view, presentation, script, and custom business logic files.

The following table describes the form files and lists their extensions.

Name Extension Description
Form definition .xsf An InfoPath-generated file that contains information about all of the other files and components used in a form. This file serves as the manifest for the form.
XML Schema .xsd The XML Schema files that are used to constrain and validate a form's underlying XML document files.
View .xsl The presentation style sheet files that are used to present, view, and transform the data contained in a form's underlying XML document files.
XML template .xml The .xml file that contains the default data that is displayed in a view when a new form is created.
Presentation .htm, .gif, .bmp, and others The files used to create custom user interface elements.
Business logic .js, .vbs The script files (JScript and VBScript) that contain programming code used to implement specific editing behavior, data validation, event handlers, control of data flow, and other custom business logic.
Binary .dll, .exe The custom Component Object Model (COM) components that provide additional business logic. These files are external to the form template file and must be registered separately.
Form template .xsn The compressed file format (.cab) that packages all the form files into one file.

Note  InfoPath automatically packages the InfoPath form files as an .xsn file, which is simply a CAB file that uses an .xsn extension. You can extract these files to a folder on your hard disk by clicking Extract Form Files on the File menu when designing a form.

The Events

Like other Office applications, InfoPath implements a number of events that can be used to respond to an application state or user-initiated action. It also implements a number of events that respond to changes in a form's underlying XML document.

There are essentially two types of InfoPath events: form events and data validation events. Form events respond to the state of the application or to a user-initiated action, and data validation events respond to changes in a form's underlying XML document.

The following table lists each of the InfoPath events and describes what they can respond to.

Event Type Description
OnLoad Form Used to initialize the form as it is being opened. This event occurs before the initial view is displayed.
OnSwitchView Form Used when switching from one view to another. This event occurs when a user changes views or when a view is first loaded.
OnBeforeChange Data validation Used after changes to a form's underlying XML document have been made but before the changes are accepted.
OnValidate Data validation Used after changes to a form's underlying XML document have been accepted but before the OnAfterChange event occurs.
OnAfterChange Data validation Used after changes to a form's underlying XML document have been accepted and after the OnValidate event has occurred.
OnSubmitRequest Form Used when the submit operation is invoked either from the InfoPath user interface or by using the Submit method of the XDocument object in the InfoPath object model.
OnVersionUpgrade Form Used to verify that the version number of the form being opened matches the version number of the form template that it is being opened with. If the version numbers do not match, this event occurs and scripting code can be used to update the form or display an error message.
OnAfterImport Form Used to provide additional processing after a form has been merged with another form. This event occurs after data is imported from another form, and scripting code can be used to set the appropriate view based on the merged data contained in the form.
OnClick Form Used to respond to a button on a form being clicked.

Note  In some cases, the data validation events may occur more than once. For example, when users insert new data, the OnBeforeChange and OnAfterChange events will occur once for an insert operation. However, when users update existing data, the events will occur twice as a delete, and then an insert operation will occur.

InfoPath also implements event objects that are passed as parameters to each of the events. These event objects are used to get a reference to the form's underlying XML document, return the status of the event, return information about an XML node during an XML Document Object Model (DOM) change, and return an error. The properties and methods available in the event objects depend on which events you are using.

The following table summarizes the event objects, the events that they are associated with, and the functionality that the event objects provide.

Event object Event Description
DocEvent OnSwitchView, OnAfterImport Returns a reference to a form's underlying XML document during a switch view or form merge operation.
DocReturnEvent OnLoad, OnSubmitRequest Returns a reference to a form's underlying XML document and the return status during the loading or submission of a form.
VersionUpgradeEvent OnVersionUpgrade Returns a reference to a form's underlying XML document, the return status, and the document and solution version numbers during the version upgrade operation.
DataDOMEvent OnBeforeChange, OnValidate, OnAfterChange Returns a reference to a form's underlying XML document, the return status, and other properties that contain information about the XML node during an XML DOM change. Also includes a method for raising an error.
DocActionEvent OnClick Returns a reference to a form's underlying XML document, the return status, and the source XML node during a button click in the form.

Overview of the Programming Environment

As mentioned previously, the programming environment for InfoPath is the Microsoft Script Editor (MSE), and Microsoft JScript and VBScript are the programming languages used in MSE to design custom business logic for a form. Working with MSE in InfoPath involves a number of tasks, including setting the default programming language, launching MSE, creating event handlers, debugging scripting code, using the object browser, and occasionally getting programming Help.

Setting the Default Programming Language

To set the default scripting language used in a form, you click Form Options on the Tools menu in InfoPath design mode, and then select the scripting language in the Form script language list on the Advanced tab of the Form Options dialog box, as shown in Figure 1. After you have selected the default scripting language and written some initial programming code, you will not be able to change the scripting language used in a form because the Form script language list will be disabled.

Advanced form options

Figure 1. Advanced form options

Note  Although InfoPath supports using either JScript or VBScript in a form, you cannot mix the two programming languages in a single form.

Launching MSE

To extend the functionality of a form by using scripting code, you must have your form open in InfoPath design mode so that you can start MSE. With the form in design mode, you can launch MSE in several ways:

  • Point to Script on the Tools menu, and then click Microsoft Script Editor.
  • Press ALT+SHIFT+F11.
  • Choose to create or edit an event handler from the Script submenu of the Tools menu.
  • Choose to create or edit an event handler from an InfoPath dialog box.

Note  Certain InfoPath event handlers are accessed from dialog boxes that are opened from the Tools menu, or from the Properties dialog boxes that are associated with some of the InfoPath controls that you use when designing a form. This is covered in more detail in the next section.

When you open MSE from InfoPath design mode, the MSE code editor appears and the form's default scripting file (with either a .js or .vbs extension, depending on the default scripting language set for the form) opens in the code editing window.

Creating Event Handlers

When writing scripting code to respond to a specific InfoPath event, you must first create an event handler, which is a function declaration that InfoPath creates in a form's primary scripting file. Event handlers are created in the design mode user interface. Event handlers must be created in this manner because InfoPath creates the function declarations for the events and also makes the necessary entries in the .xsf file that enable the form to use the event handlers.

Note  It is possible to create the event handlers manually in the scripting file and then make manual entries directly in the .xsf file, but this is not recommended. Event handlers that are created manually may not get created accurately and could cause the form to function improperly.

How you create the event handlers depends on the type of event that you want to use. Some event handlers are created from the Script submenu of the Tools menu, and others are created by using one of InfoPath's various dialog boxes.

The following table lists each of the InfoPath event handlers and the steps for creating them.

Event handler Steps
OnLoad On the Tools menu, point to Script, and then click On Load Event.
OnSwitchView On the Tools menu, point to Script, and then click On Switch Views Event.
OnBeforeChange In the Events list in the Data Validation dialog box (which is accessible from the Data tab of a control's Properties dialog box or the Format menu), click OnBeforeChange.

The OnBeforeChange event handler can also be created by clicking the Validation and Script tab in a control's Field or Group Properties dialog box, and then clicking OnBeforeChange in the Events list.

OnValidate In the Events list in the Data Validation dialog box (which is accessible from the Data tab of a control's Properties dialog box or the Format menu), click OnValidate.

The OnValidate event handler can also be created by clicking the Validation and Script tab in a control's Field or Group Properties dialog box, and then clicking OnValidate in the Events list.

OnAfterChange In the Events list in the Data Validation dialog box (which is accessible from the Data tab of a control's Properties dialog box or the Format menu), click OnAfterChange.

The OnAfterChange event handler can also be created by clicking the Validation and Script tab in a control's Field or Group Properties dialog box, and then clicking OnAfterChange in the Events list.

OnSubmitRequest On the Tools menu, click Submitting Forms. In the Submitting Forms dialog box, click Submit using custom script in the Submit list.
OnVersionUpgrade On the Tools menu, click Form Options. In the Form Options dialog box, click the Advanced tab, and then click Use script event in the On version upgrade list.
OnAfterImport An exception to the rule of using the design mode user interface for creating event handlers, this event handler cannot be created in design mode. It must instead be created manually.
OnClick In the Button Properties dialog box for the button control, click Microsoft Script Editor.

When you create an event handler in design mode, InfoPath creates the event handler's declaration in the form's primary scripting file and then automatically opens MSE, displaying the newly created event handler in the code editing window. In the declaration of the event handler, InfoPath uses eventObj as the name of the parameter that is passed to the event handler. This parameter contains a reference to the event object that is associated with the event handler.

For example, when you create the OnLoad event in design mode, InfoPath creates the OnLoad event handler in the scripting file and then opens MSE so that you can write your scripting code within the event handler declaration.

If you are using JScript as the default scripting language, the OnLoad event handler is declared as follows:

    //======= 
// The following function handler is created by Microsoft Office
// InfoPath. Do not modify the name of the function, or the name 
// and number of arguments. 
//======= 
function XDocument::OnLoad(eventObj)
{
   // Write your code here
}

  

If you are using VBScript as the default scripting language, the OnLoad event handler is declared as follows:

    //======= 
// The following function handler is created by Microsoft Office
// InfoPath. Do not modify the name of the function, or the name 
// and number of arguments. 
//======= 
Sub XDocument_OnLoad(eventObj)
   ' Write your code here
End Sub
  

Note  After you have created the InfoPath event handlers, do not modify their declaration: doing so may cause the form to function improperly.

Debugging Scripting Code

A common feature of integrated development environments is the ability to debug the code you have written. Debugging programming code involves either choosing to debug the code when an error occurs or setting a breakpoint in the code that tells the debugger when to suspend program execution, allowing you to step through your code and examine its behavior.

To debug the code that is used to customize an InfoPath form, you can use a programming debug statement in your code. In JScript, use the debugger; statement; in VBScript, use the Stop statement. After you have entered a debug statement in your code, save the code and preview your form.

The following example demonstrates how to use the debug statement in the OnLoad event handler by using JScript syntax:

    function XDocument::OnLoad(eventObj)
{
   debugger;
}
  

If you are using VBScript as the default scripting language, the debug statement can be used as follows:

    Sub XDocument_OnLoad(eventObj)
   Stop
End Sub
  

Note  To use script debugging, make sure that the Disable script debugging check box is cleared on the Advanced tab of the Internet Options dialog box in Microsoft Internet Explorer. You can open this dialog box by clicking Internet Options on the Internet Explorer Tools menu.

When you preview or open a form that has a debug statement in it, the Just-In-Time Debugging dialog box appears, prompting you to select the debugger that you want to use, as shown in Figure 2. Click New instance of Microsoft Script Editor, and then click Yes. The Step Into Remote Procedure Call dialog box prompts you to select the program type that you want to debug. Click Script, and then click OK. MSE opens in debug mode and displays a yellow arrow indicating where program execution has been suspended.

The Just-In-Time Debugging dialog box

Figure 2. The Just-In-Time Debugging dialog box

With MSE in debug mode, you can use all of the debugging features that it provides, including setting breakpoints, stepping through program statements, and viewing any of the debugging windows such as the Watch, Immediate, and Call Stack windows.

To stop debugging your scripting code, click Stop Debugging on the Debug menu, or press SHIFT+F5.

Note  You can also choose to debug when an error occurs in your code as you are previewing or using your form.

Using the Object Browser

Similar to the Visual Basic for Applications (VBA) programming environment, MSE provides an object browser that you can use to examine the contents of the InfoPath object model. With the object browser, you can view all of the objects of the InfoPath object model and all of the properties, methods, and events that are associated with them.

To open the MSE object browser, shown in Figure 3, do one of the following:

  • Point to Other Windows on the View menu, and then click Object Browser.
  • Press CTRL+ALT+J.
  • Click the Object Browser button on the Standard toolbar.

The MSE object browser

Figure 3. The MSE object browser

If the InfoPath object model does not appear in the MSE object browser, do the following:

  1. Open the MSE object browser.
  2. Click Customize in the object browser window.
  3. In the Selected Components dialog box, click to expand the Other Packages and Libraries node in the components list.
  4. If InfoPath - Microsoft Office InfoPath 1.0 Type Library is displayed in the list, select its check box and click OK. If it isn't, continue to the next step.
  5. Click Add.
  6. In the Component Selector dialog box, select Microsoft InfoPath 1.0 Type Library, click Select, and then click OK to close the dialog box.
  7. Ensure that InfoPath - Microsoft Office InfoPath 1.0 Type Library is displayed and selected in the Selected Components dialog box, and then click OK.

Getting Programming Help

When you are developing a custom solution using InfoPath or some other Office application, it is often useful to look for developer-oriented Help content that can assist you in understanding the application or in solving some sort of development problem. InfoPath contains a variety of Help content aimed at helping form developers customize and extend the forms that they design. The primary resources for InfoPath form development Help are the InfoPath Developer's Reference, the MSE Help system, and various online resources.

The InfoPath Developer's Reference

The following resources are available in the InfoPath Developer's Reference, which is available in the InfoPath Help system and the MSE Help system:

  • Programming Concepts   This set of topics includes conceptual information about programming InfoPath, including the InfoPath object model and .xsf file.
  • Developer Sample Forms  This set of topics includes documentation for the five developer sample forms installed with InfoPath that demonstrate some of the key features of InfoPath form development.
  • InfoPath Object Model Reference  This set of topics provides the complete set of documentation for the InfoPath object model, including all of its collections, objects, properties, methods, events, and enumerations.

    Note  The InfoPath object model is F1-enabled: if you place the insertion point in a particular object model member in the MSE code editing window and then press F1, the reference topic for that member displays.

  • InfoPath XSF Reference  This set of topics provides the complete set of documentation for the InfoPath .xsf file, including all of its namespaces, groups, types, elements, and attributes.

The MSE Help System

The following resources are available in the MSE Help system, which is available only when working in MSE:

  • Microsoft Script Editor Help  This set of topics provides information about using MSE, from customizing the script editor to debugging techniques.
  • Microsoft XML Core Services (MSXML) 5.0 SDK  This set of topics provides information about using XML, the XML Document Object Model (DOM), XML Schemas, XSL Transformation (XSLT), and XPath. It includes various developer guides and language references that discuss each of these XML-based technologies.
  • JScript Reference  This set of topics provides information about using the Microsoft JScript programming language, including a language reference and tutorial.
  • VBScript Reference  This set of topics provides information about using the Microsoft VBScript programming language, including a language reference and tutorial.

Online Resources

In addition to the Help resources included with InfoPath, a number of online resources are available as well:

Overview of the InfoPath Object Model

The InfoPath object model is a Component Object Model (COM)-based object model that can be used to interact with InfoPath forms and their underlying XML documents. It is similar to other Office application object models in that it implements interfaces for collections, objects, properties, methods, and events. However, the InfoPath object model supports only a limited set of methods for automating the InfoPath application.

Object Model Functional Areas

The InfoPath object model contains objects that represent key functional areas of an InfoPath form that you can interact with programmatically. The following table details some of these key objects.

Object Description
Application The Application object is the top-level object in the InfoPath object model. It provides a number of properties and methods that can be used to access lower-level collections and objects in the object model and to perform a variety of general-purpose functions.
Window The Window object provides a number of properties and methods that can be used to programmatically interact with InfoPath windows, including the ability to activate or close a window and the ability to interact with the task panes and command bars that they contain. The Window object also provides a property for accessing the form's underlying XML document that is associated with the window.
XDocument The XDocument object provides a number of properties, methods, and events that can be used to programmatically interact with and manipulate the source XML data of a form.
MailEnvelope The MailEnvelope object provides a number of properties that can be used to programmatically create a custom e-mail message in the Microsoft Office Outlook 2003 e-mail editor, and it attaches the currently open InfoPath form to the message.
TaskPane The TaskPane object provides a number of properties for working with the InfoPath built-in task panes and custom task pane.
DataObject The DataObject object provides properties and methods that can be used to programmatically interact with data adapter objects, including retrieving information about the data adapter objects and accessing the data that they connect to.
Error The Error object provides a number of properties that can be used to programmatically interact with an InfoPath-generated error.
Solution The Solution object provides a number of properties for getting information about a form template, including its version number, the URL of its extracted form files, the URL it was loaded from, and an XML Document Object Model (DOM) containing its .xsf file.
UI The UI (user interface) object provides a number of methods for displaying custom and built-in dialog boxes.
View The View object provides a number of properties and methods that can be used to programmatically interact with an InfoPath view, including methods for selecting data contained in the view, switching from one view to another, synchronizing the view with a form's underlying XML document, and executing an InfoPath editing action.
ViewInfo The ViewInfo object provides properties that can be used to get the name of a view and determine whether a view is the default view of the form.
ExternalApplication The ExternalApplication object implements a limited set of methods that can be used for automating InfoPath by an external COM-based programming language.

Object Model Access

The InfoPath object model is accessed through scripting code, except for the ExternalApplication object, which can be accessed by any COM-compliant programming language. Scripting code can be used in a variety of ways in an InfoPath 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 in 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.

Object Model Security

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, including the types of forms that have access to them.

The InfoPath object model security levels are as follows:

  • 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.

You can develop two types of forms in InfoPath: standard and fully trusted. Standard forms are identified by a URL and run in a cached location on the user's computer. They are restricted from accessing any of a system's resources and are therefore unable to pose a threat to the security of the system. Also, standard forms cannot make use of custom COM components. Standard forms cannot access any object model member with a security level of 3. Calling an InfoPath object model member without the proper permissions for its security level will result in a "permission denied" error.

Fully trusted forms are identified by a Uniform Resource Name (URN) and are allowed to have full access to a system's resources. They can make use of custom COM components, and they can make calls to the InfoPath object model members that have a security level of 3.

Overview of the InfoPath Form Definition File

The InfoPath form definition (.xsf) file is the central file of a form: it contains information about how a form is put together, including the XML Schemas that it uses, the resource files that it contains, the event handlers that it implements, and a variety of other aspects related to its general operation and appearance.

Form Definition File Customizations

The .xsf file is an XML file that is created by InfoPath when you design a form and then continually updated as you make modifications to the form. For most tasks related to form design and development, it is best to let InfoPath create and maintain the .xsf file. However, to extend the functionality of a form, you can make some modifications to the .xsf file that are not available in InfoPath design mode.

The following are some of the more common modifications that you can make to the .xsf file:

  • Extending the user interface by adding submenus to the menu bar and toolbars
  • Adding multiple script files
  • Creating fully trusted forms
  • Overriding default error messages
  • Adding extra print settings
  • Adding extra toolbars
  • Adding extra top-level menus
  • Creating buttons on menus and toolbars that call scripting functions

Form Definition File Key Elements

The .xsf file contains a number of key elements that are used by InfoPath to store information about a form, and many of these key elements have other elements nested within them. The following table details some of these elements.

Element Description
applicationParameters Contains form-specific properties that describe how a form should be used in InfoPath design mode
customValidation Defines rule-based custom validation on top of all validation enforced through the XML Schema
dataObjects Defines all secondary data objects used in a form
documentSchemas Defines the XML Schemas that the form is designed to use
documentSignatures Defines the location of the digital signature XML DOM node within the form's underlying XML document
documentVersionUpgrade Defines how forms created with an older version of the form template can be upgraded to the latest version of the form template
domEventHandlers Contains pointers to various script-based event handlers that react to changes in the XML DOM nodes of a form's underlying XML document
fileNew Provides a reference to an .xml file containing sample data to be loaded when a user chooses to design a new form based on the form template
importParameters Contains all the parameters that define how the merge forms (import) feature works for the form
listProperties Identifies the properties that should be on a list view of all forms belonging to the form template
package Contains information about all of the files used in a form
query Associates a data adapter with a data object or a form's underlying XML document
schemaErrorMessages Contains custom error messages used to override XML Schema data type errors
scripts Defines the source of all business logic scripts used at the document level in the form
submit Contains information about the submission functionality of a form
taskpane Defines a custom task pane to be used in a form
views Defines all of the views that have been implemented in a form

Key Areas of InfoPath Development

Along with the development components involved with customizing an InfoPath form, two key areas of InfoPath development are also involved. One is the programming components that can be used to customize a form, and the other is the concept of programmatic and declarative development.

Programming Components

InfoPath programmability involves customizing an InfoPath form by altering its form files or by writing scripting code to create custom functions by using the InfoPath object model. The main components of an InfoPath form that can involve programmatic interaction are listed in the following table.

Component Description
Object model A robust, hierarchical type library composed of collections, objects, properties, methods, and events that give form developers programmatic control over various aspects of the InfoPath editing environment and access to a form's underlying XML document.
Data validation A combination of XML Schemas, expressions, and scripting code used to validate and constrain the data that users are allowed to enter into a form.
Event handling A set of event handlers that respond to changes to a form's underlying XML document, respond to view switching, implement custom form submission, or respond to the loading of the form's underlying XML document.
User interface A set of customizable user interface components that includes menus, toolbars, buttons, command bars, and a task pane.
Editing controls A set of InfoPath-specific controls used to manage and interact with the form's underlying XML document that includes collections, optional items, text lists, and fields.
Error handling A combination of event handlers, object model calls, and .xsf file entries that are used to handle errors in an InfoPath form.
Security A set of security levels that restrict access to the InfoPath object model and system resources.
Data submission A set of predefined functions that can be used to implement custom posting and submission functionality for an InfoPath form.
Business logic 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 COM components.
Form integration Integration of other Office applications such as Microsoft Excel or Microsoft Outlook. Integration may also involve the use of back-end servers such as Microsoft SQL Server, Microsoft Windows SharePoint Services, or XML Web services.

Programmatic and Declarative Programming

When you alter the InfoPath form files, you customize the form declaratively that is, you open the form files in some type of standard text editor and manually change the elements, attributes, and values of the files. When you alter a form programmatically, you write programming code by using a scripting language in conjunction with the InfoPath object model and, in some cases, external COM components to extend and enhance form behavior.

The following are some of the ways in which a form may be customized declaratively:

  • Modifying the XML Schema (.xsd) files
  • Modifying the view (.xsl) files created in design mode
  • Modifying the .xsf file
  • Modifying the XML template (.xml) file

The following are some of the ways in which a form may be customized programmatically:

  • Adding form lifecycle processing logic
  • Adding custom data validation
  • Adding custom error handling
  • Implementing data submission
  • Responding to a form merge (or import)
  • Using custom task panes
  • Using custom dialog boxes
  • Accessing and modifying a form's underlying XML document
  • Accessing and modifying the XSF file
  • Using external COM components

Developing a Simple Form

In the following example, you will design a simple InfoPath form that contains a text box for entering data and a button for executing some scripting code that uses that data.

  1. If you haven't done so already, start InfoPath.
  2. In the Fill Out a Form task pane, click Design a Form. (If the Fill Out a Form task pane is not visible, click Fill Out a Form on the File menu.)
  3. In the Design a Form task pane, click New Blank Form to open a blank form in InfoPath design mode.
  4. Click Form Options on the Tools menu.
  5. On the Advanced tab in the Form Options dialog box, select an option as the default scripting language in the Form script language box, and then click OK.

    Note  This example uses JScript.

  6. In the Design Tasks task pane, click Data Source.
  7. In the Data Source task pane, click myFields under Work with the data source. This enables the Add button at the bottom of the task pane.
  8. Click Add to open the Add Field or Group dialog box.
  9. Type SimpleMessage for the Name field, and then click OK. You will see the SimpleMessage field listed in the data source.
  10. Click the SimpleMessage field and drag it onto the form to create a text box with the label "Simple Message:".
  11. In the Data Source task pane, click Controls.
  12. In the Controls task pane, click the Button control and drag it onto the form.
  13. Right-click the button control on the form, and then click Button Properties to open the Button Properties dialog box.
  14. On the General tab, click Microsoft Script Editor to open MSE and create the OnClick event handler for the button.
  15. In the OnClick event handler, enter the following code:
    var strMessage; 
    strMessage = eventObj.Source.selectSingleNode("//my:SimpleMessage").text; 
    XDocument.UI.Alert(strMessage);
    

    Note  This code sample uses the Source property of the event object that is passed as a parameter to the OnClick event handler. The Source property returns a reference to the XML DOM node that is currently being used in the form. In this case, it is the XML DOM node that contains the data from the Simple Message field. Note the use of the XML DOM selectSingleNode method for accessing the data contained in the XML DOM node. Also note the use of the Alert method of the UI object, which is used to display a simple dialog box that contains a text message.

  16. Click Save on the MSE File menu, and then quit MSE.
  17. In InfoPath, click Preview Form on the Standard toolbar.
  18. Enter some text in the Simple Message field, and then click the button. A simple dialog box appears that contains the text you just entered.
  19. Click Close Preview on the Standard toolbar to return to InfoPath design mode.

This form simply serves to demonstrate some of the more common development tasks in InfoPath, which are summarized in the following table.

Task Description
Design a form Using the Fill Out a Form and Design a Form task panes, you designed a blank form and opened it in InfoPath design mode.
Set the default scripting language Using the Form Options dialog box, you set the default scripting language for the form.
Create a data source Using the Data Source task pane, you created a simple data source for the form. Behind the scenes, InfoPath created an XML Schema (.xsd) file.
Add a bound control to a form Using the Data Source task pane, you dragged a control onto the form and created a bound field.
Add an unbound control to a form Using the Controls task pane, you dragged a button control onto the form and created an unbound control.
Create a view for the form By default, all forms implement a single default view. As you added controls to the form, InfoPath created the XSL Transformations (.xsl) for the view.
Create an event handler Using the Button Properties dialog box, you created an event handler for the button control and opened MSE.
Write scripting code In the OnClick event handler for the button control, you used scripting code to interact with the InfoPath object model.
Preview and test a form Using the Preview Form button on the toolbar, you previewed and tested your form.

Conclusion

InfoPath, like many other Microsoft Office applications, provides a rich development environment for customizing the forms that it creates. Using such development components as the Microsoft Script Editor, the InfoPath object model, the InfoPath .xsf file, and scripting languages, you can customize your forms to extend their basic functionality so that they meet your specific business requirements.





Show:
© 2015 Microsoft