What email address or phone number would you like to use to sign in to Docs.com?
If you already have an account that you use with Office or other Microsoft services, enter it here.
Or sign in with:
Signing in allows you to download and like content, which the author will be aware of.
Embed code for: InfoPath 2013 Training
Select a size
Microsoft Office InfoPath 2013 Training
This course is intended for Support Engineers supporting Microsoft Office InfoPath 2013. This training combines self-study reading material and hands-on labs to demonstrate many of the new features of Office InfoPath 2013. Topics covered include:
To provide a good foundation for exploring the Microsoft Office InfoPath 2013 product and creating functional form templates. To provide an overview of InfoPath in enough depth to enable Microsoft Product Support Services Support to support customers using InfoPath to create solutions.
Knowledge and experience with Extensible Markup Language (XML), Extensible Schema Definitions (XSD), and Extensible Stylesheet Transforms (XSLT)
Knowledge and experience programming in either C# or Visual Basic .NET
Knowledge and experience with Windows SharePoint Services and Microsoft Office Server System
NOTE: Items marked with “” are new for InfoPath 2013
Level 100-300 2
Prerequisite Knowledge 4
Administrator Configurable Settings 14
Starting InfoPath 17
Getting Started dialog (InfoPath 2007) 17
Form Categories 18
Other Options 19
New Form in InfoPath Filler (InfoPath 2010 and 2013) 20
Get Updates of Forms 21
To update a group of forms (InfoPath 2007 only) 21
To update a specific form (InfoPath 2007) 22
To update a specific form (InfoPath 2010 and 2013) 22
InfoPath Workspace 23
The Form Area 23
The Task Pane 23
The Task Pane in InfoPath 2007 23
The Task Pane in InfoPath 2010 and 2013 24
Views Task Pane (InfoPath 2007 only) 24
Fields Task Pane 25
Controls Task Pane 27
Layout Task Pane (InfoPath 2007) 46
Design Checker Task Pane 47
The Ribbon 48
Page Design Ribbon 48
Data Ribbon 48
InfoPath Form Template Component Files 49
The Form Definition File 49
Sample Data 49
Script Deprecated in InfoPath 2010 and 2013 50
Managed Code 50
A Note on File Names 50
Designing a New Form Template 51
Designing a New Form Template in InfoPath 2007 51
Designing a New Form Template in InfoPath 2010 and 2013 51
Form Template Types 52
Form Template types available in InfoPath 2007 52
Form Template types available in InfoPath 2010 and 2013 53
Creating a New Blank Form 54
Designing the View 54
Designing the XML Schema 54
Adding a Field or Group 55
Referencing an Existing Field or Group 56
Moving a Field or Group 57
Creating a new form from a Data Source 58
Creating a form using an XML Schema or XML data file 60
Starting from a Database 61
Multiple Tables 63
Custom SQL Queries 64
Submitting to a Database 65
Starting from a Web Service 65
Submitting Data to a Web Service 66
Receiving Data from a Web Service 66
Receive-Submit Hybrid forms (InfoPath 2007) 67
Adding Submit capabilities to a Receive-style form 68
Web Services and ADO .NET Datasets (InfoPath 2007) 70
Changing Data Sources and Server Names 71
Data Connection Library 71
Starting from a Connection Library 73
Importing Forms 76
Importing Excel forms 76
Importing Word forms 79
Design Checker Note 83
Controls and Data Binding 84
Binding Controls using the Controls task pane 84
Binding Controls using the Fields task pane 84
Changing the Data Binding of a Control 86
Control ID’s 88
Secondary Data Sources 90
Setting Up a Secondary Data Source 90
Storing a copy of the data for offline use 90
SharePoint List Data Connection 94
REST Web Service Data Connection (InfoPath 2010 and 2013) 94
Binding Controls to a Secondary Data Source 95
Using a Secondary Data Source in controls 95
Using a Secondary Data Source from code 97
Filtering Repeating Tables and Sections 98
Filtering ListBox Choices 99
Unique Entries 100
Conditional Formatting 102
Conditional Formatting in InfoPath 2007 102
Conditional Formatting in InfoPath 2010 and 2013 103
Data Validation 105
Data Validation User Interface 105
Inline Alerts 105
Dialog Box Alerts (Rich client forms only) 106
Active Dialog Box Alerts (client only) 106
XML Schema Validation 106
Custom Data Validation 107
Adding Data Validation in InfoPath 2007 107
Adding Data Validation in InfoPath 2010 and 2013 108
Constructing Validation Rules 109
Data Validation using Patterns 109
Code based Data Validation 110
Creating Code-based Data Validation in InfoPath 2007 110
Creating Code-based Data Validation in InfoPath 2010 and 2013 110
InfoPath 2010 Data Validation Events 111
When a Field or Group changes 114
When the Form is opened 114
When a button is clicked 114
When the form is submitted 114
Actions in rules 115
Rule Inspector 116
Launching the Logic Inspector in InfoPath 2007 116
Launching the Rule Inspector in InfoPath 2010 and 2013 116
Rule Inspector Views 117
Defining User Roles 119
Working with user roles 120
Testing User Roles 120
Publishing and Security 121
Full Trust 121
Specifying a Security Zone 121
Publishing a form template 122
Publishing to SharePoint 123
Publish to a list of e-mail recipients 132
Publish to a network location 135
Publish as an installable form template (InfoPath 2007 only) 137
Design Checker Task Pane 139
Errors vs. messages 140
View errors and messages from a server running InfoPath Forms Services 142
InfoPath Forms Services 143
Extend the reach of your form templates 143
Designing a form template for Forms Services in InfoPath 2007 143
Hidden controls 145
Designing a form template for Forms Services in InfoPath 2010 and 2013 146
Form Template Browser options 147
Submitting Data 149
Managing browser-enabled templates 149
Quiesce Form Template 149
Deactivate Form Template 150
Remove Form Template 150
InfoPath Forms Services Configuration Options 151
Post Backs (Refreshing data) 153
Backup and Restore 153
InfoPath E-Mail forms 155
Using InfoPath Forms folders to display data 155
Analyzing Form Data 158
Merge Forms 158
Export forms to Excel 158
Export InfoPath e-mail forms as InfoPath XML files 159
InfoPath e-mail forms with Restricted Permissions 159
Digital Signatures 161
Signing the Entire Form 163
Signing individual sections 163
Additional Digital Signature Options 164
Protecting a Form Template from Accidental Changes 166
Overwrite Protection 166
Form Template Versioning 166
Document Recovery 167
Disable Features 168
Exporting Forms 169
Send to Mail Recipient 169
Export to the Web 169
Export to Excel 170
Export to PDF or XPS 172
Submitting Forms 173
Enabling Form Submission 173
Submit to SharePoint Data Connection 173
Submit through Email Data Connection 176
Submit to Hosting Environment 179
Post-Submit Options 180
InfoPath Events and the Programming environment 182
The Loading Event 182
The ViewSwitched Event 182
The Changing, Validating, and Changed Events 182
The Submit Event 183
The VersionUpgrade Event 183
The Clicked Event 184
The ContextChanged event 185
The Merge event 187
The Save event 188
The Sign event 189
Off-line mode 191
Selecting the Programming Language 191
Debugging Script in InfoPath Event Handlers 192
Merging Forms 194
How Merging Forms Works 194
Merging from XML Location Paths 195
Merging from InfoPath Aggregation Instructions 195
Default Form Merge Functionality 197
Custom merging via the UI 198
Repeating Groups 198
Non-Repeating Groups 198
Repeating Fields 199
Non-Repeating Fields 199
Attribute Fields 200
Rich-Text Fields (Repeating and Non-Repeating) 201
Custom Form Merging via XSL Transform 202
Customizing Views 206
Preserving Changes to a View 206
Conditionally displaying scroll bars 206
Read-Only Views 207
Bound fields in header and footer 208
Extending the InfoPath Control Set with Custom ActiveX Controls and Template Parts 210
ActiveX Controls 210
Custom Control Bindings 210
Adding custom ActiveX Controls 210
Adding ActiveX Controls to Forms 215
Control Installation 215
Writing ActiveX Controls for InfoPath 215
Deploying ActiveX Controls to Developers 216
Template Parts 217
Creating a Template Part 217
Adding a Template Part to an InfoPath template 217
Updating a Template Part 219
Document Information Panels 220
Starting from SharePoint 221
Starting from InfoPath 223
Publishing Custom Document Information Panels 224
Publishing Locations 225
Security Considerations 225
Information Rights Management 226
Protecting a form template 226
Protecting form data 229
IRM Object Model 232
Opening IRM Protected forms 233
Using IRM from Windows SharePoint Server 234
IRM with Merged Forms 234
Browser-compatible forms 234
InfoPath 2003 compatibility 234
Hosting InfoPath Forms 236
Hosting InfoPath Forms in Windows Form Applications 236
Hosting InfoPath Forms in custom web pages 238
Opening the SharePoint Site and Creating a custom Web Page 238
Setting Page Properties and Adding the XmlFormView Control 239
Configuring SharePoint and Resetting IIS 239
Load web-enabled InfoPath Form Templates in the Control 239
Coding with the XmlFormView Control 239
Getting a Value from the Form to the Web Page 240
Microsoft Office InfoPath is an authoring tool that allows users to easily create and modify rich, dynamic forms. It presents a WSYIWYG design mode for drag-and-drop form creation and an Office-like environment for filling out forms. The information gathered can be easily reused throughout organizations and across multiple business processes because the native file format for InfoPath forms is industry-standard Extensible Markup Language (XML). Users get the power of XML without having to know anything about the details of schemas, transforms, and so on. Programmability through a script editor, object model, and event notifications allows developers to create forms that ensure data consistency and correctness.
InfoPath provides a rich user experience for users as they fill out forms. InfoPath provides data validation for a form as the user fills it out. Validation can detect errors at the schema level, through logical constraints, and even through managed code. This validation occurs immediately, so the user doesn't have to submit the entire form before finding out there's an error.
InfoPath also provides conditional formatting, so your form can be more responsive to user input. For example, you might have a field whose background color changes to red whenever an unusual (but not illegal) value is entered. Conditional formatting also occurs as soon as the value is entered, so the user has a chance to react appropriately.
InfoPath allows users to work on a form offline and to interrupt work on a form and come back to it at a later time. InfoPath can easily make use of Microsoft SQL Server and Microsoft Access databases, existing XML files and Web services without requiring form designers to write low-level code. InfoPath also provides the ability to easily merge data from multiple forms into one form.
InfoPath includes an object model, editing controls, and a clear-text XML format for various form files. These tools give developers the ability to design views, add custom code, control the run-time behavior of a form, and integrate custom forms directly with a server or Web service.
By using XML as its native file format, InfoPath provides a way to easily separate data from how it’s presented. This means that data entered into InfoPath forms can be easily moved from one document or database to another without having to be reentered. Finally, InfoPath integrates with Microsoft SharePoint and Microsoft Outlook to facilitate collaboration with other users.
InfoPath makes a distinction between the data in a form and the way it is presented to the user. The data in a form is stored in an industry-standard Extensible Markup Language (XML) file. This XML file contains only the filled out form data, with no information on how that data should be presented to the user. In general discussion, this XML file is typically called the form.
All of the information on how the form template should be presented, as well as the rules on how the data in a form is validated, updated, and managed, is stored in a custom file with an XSN file extension. In general discussion, this XSN file is typically called the form template, to distinguish it from a data file, or simply the form, when such distinction is not required. For more information on the form template file, see the InfoPath Form Template Component Files section.
To install InfoPath 2013, you need Windows 7 or later. 1 GB of RAM is recommended. InfoPath also requires Microsoft Internet Explorer 8 or later to be installed.
Administrator Configurable Settings
By using the Microsoft Office 2013 “/Admin” switch with Setup.exe, administrators can configure many of the InfoPath features and user settings. Most of these settings are self-explanatory, but there are a few in the Security section that deserve special note. The Disable opening forms with managed code from the Internet Security zone, Disable opening of solutions from the Internet security zone, and Disable fully trusted solutions full access to machine options can dramatically change the way that InfoPath behaves for users. If users find that they are impacted by these settings, check the Registry to determine if options have been set. InfoPath stores these options under the following keys:
Figure 1: Microsoft Office 2010 Admin Setup Options
The user settings configurable by an administrator include:
Microsoft InfoPath 2010 (Machine) Security
InfoPath ATCPA Assembly allowable list
Controls whether assemblies marked as “Allow partially trusted callers” can be used from an InfoPath form template
Windows Internet Explorer Feature Control Opt-In
Controls whether Internet Explorer provided features, such as installing ActiveX Controls and URL navigation are permitted.
InfoPath APTCA Assembly Allowable List Enforcement
Controls whether InfoPath enforces the safe list of assemblies stored in the GAC.
The number of entries displayed in the Recently used file list
Left-to-right (LTR) or right-to-left (RTL) text direction
Spelling and Grammar
Hide spelling errors
East Asian Language Find
Match full/half width forms
Match minus, dash, cho
Match cho-on used for vowels
Set EA line breaking
Display a warning dialog box that user is entering text in Ink entry mode
Enter milliseconds before recognizing handwriting
Display a shaded ink guide for handwriting
Offline data cached per form template
Offline mode cache size
Offline mode status
Disable Common Language Runtime errors when filling out forms
Disable all trusted locations
Block cross-domain data form retrieval
Disable all application add-ins
Require that application add-ins are signed by Trusted Publisher
Disable Trust Bar Notification for unsigned application add-ins
Turn off Data Execution Prevention
Disable opening forms with managed code from the Internet Security zone
Control behavior for Microsoft SharePoint Foundation Gradual Upgrade
Disable opening of solutions from the Internet security zone
Disable fully trusted solutions full access to machine
Allow the use of ActiveX Custom Controls in InfoPath forms
Allow file types as attachments to forms
Block specific file types as attachments to forms
Prevent users from allowing unsafe file types to be attached to forms
Display a warning that a form is digitally signed
Beaconing UI for forms opened in InfoPath
Beaconing UI for forms opened in InfoPath Filler ActiveX
InfoPath e-mail forms
Control behavior when opening InfoPath e-mail forms containing code or script
Disable sending form template with e-mail forms
Disable dynamic caching of the form template in InfoPath e-mail forms
Disable sending InfoPath 2003 Forms as e-mail forms
Disable e-mail forms running in restricted security level
Disable e-mail forms from the Internet security zone
Disable e-mail forms from the Intranet security zone
Disable e-mail forms from the Full Trust security zone
Disable InfoPath e-mail forms in Outlook
Disable exporting InfoPath e-mail forms to Excel
Disable merging InfoPath e-mail forms
Disable exporting InfoPath e-mail forms
Email Forms Beaconing UI
Enter URL of location where template parts are stored
Disable Microsoft InfoPath Filler Control
Turn off InfoPath Designer mode
Allow users to turn on and off printing of background colors
InfoPath operates in one of two basic modes. The design mode provides the facilities needed to design a form and write code to affect the operation of the form. The edit mode provides the end-user a form ready to draw upon a data source, facilities that enable the end-user to fill out a form and the capability to submit the data within the form back to a data source.
InfoPath 2007 supports both design mode and edit mode in the same application. In InfoPath 2010 and InfoPath 2013, design mode and edit mode have been separated into two different applications, the Microsoft InfoPath Designer and the Microsoft InfoPath Filler. The Designer is where form developers create new form templates and publish them for use by information workers. The Filler is where information workers fill out published form templates.
Getting Started dialog (InfoPath 2007)
When you first start InfoPath 2007 you will see the Getting Started dialog superimposed over the InfoPath window. The Getting Started dialog box will appear when InfoPath is first launched and when selecting Fill Out a Form from the File menu. It contains all the commands needed to open and update forms as well as it provides a link to access the form design mode.
Figure 2: Getting Started dialog
The Form Categories commands allow you to filter the list of forms displayed in the center pane. The Favorites option will display the forms you have published as well as any you have added through clicking the Add to Favorites link in the Form tasks list at the right. To work with a form, select it from the list, and then choose the appropriate task from the Form tasks list. If the form template you want to work with is not displayed, you can use the On My Computer… command to browse to it.
Recently Used Forms
The first item under Form Categories is the Recently Used Forms. This is a list of the last 15 forms opened in InfoPath sorted in order of most recently to least recently opened.
InfoPath provides the ability for users to add forms they fill out to a Favorites category. When working with a large number of forms the Recently Used Forms category may not always contain a form which is important to the user. To add a form to the Favorites category select the form in the center forms list, then choose the Add to Favorites link in the Form tasks list at the right.
Displays all the forms that have been opened on this machine.
InfoPath also provides the ability to specify a custom category for a form at design time. In the figure below, TestCategory is a custom defined category.
Up to three distinct categories will be shown on the dialog. If there are more than three categories a More… link will appear below the three displayed categories. Choosing this link will open the Select Category dialog to display all the available categories. When a category is selected from the Select Category dialog it is added to the top of the list of three categories displayed on the Getting Started dialog and the last category is dropped off the list.
To add a custom category when designing a form template, choose Properties from the File menu to open the Form Properties dialog box. Check the box labeled Enable custom category. Type a category name for the form.
Figure 3: Form category dialog
The category will only appear in the Getting Started dialog box after the form is opened or cached in InfoPath. If there are multiple forms with the exact same category name, they will appear together under that category name.
You can control whether the Getting Started dialog is presented when you initially open InfoPath by checking the Do not automatically show the Getting Started dialog box option on the General tab of the Options dialog invoked from the InfoPath Tools menu, as shown in the figure below. Doing this will cause InfoPath to load and open directly to the InfoPath Workspace.
Figure 4: Options dialog from the Tools menu
New Form in InfoPath Filler (InfoPath 2010 and 2013)
When you first start the InfoPath Filler, you will see the InfoPath Backstage. The backstage contains all the commands needed to fill out a new form or open an existing form. You can also access the general InfoPath Filler options from the backstage.
Figure 5: InfoPath 2010 Form Filler Backstage
The last few form templates that have been filled out by the user will be offered to the user to be filled out. When the user selects a form template from the list, the Fill Out Form button will be displayed and the user can select this button to fill out the form. If the form template the user wishes to fill out is not listed, the user can click Find a Form to locate the form template they wish to fill out.
Form Categories such as Favorites and Custom Categories have been removed from InfoPath 2010 and 2013.
Get Updates of Forms
InfoPath forms deployed to a shared location are automatically updated whenever the form is opened on a client computer and a new version is available. Users can also get updates of forms without opening the form itself.
To update a group of forms (InfoPath 2007 only)
In the Getting Started dialog box, select the category of forms to update from the list at the top left of the dialog. In the Form tasks category choose Get Updates of Forms in this Category. A dialog shows the progress of the update for each form in the category. To cancel getting updates select Cancel in this dialog. This will cancel the update after finishing the current form update and will only cancel updating any more forms. Forms that already completed updating will not return to their previous state.
To update a specific form (InfoPath 2007)
In the Getting Started dialog box select the form from the center list of forms. Choose Get Update of This Form from the list of Form tasks category at the right of the dialog. A dialog will appear to show the progress of the update. This operation cannot be cancelled.
To update a specific form (InfoPath 2010 and 2013)
To update a form without opening it, find the form in the list of Available Forms in the InfoPath Backstage. Right-click on the form and choose Get Update of This Form. A dialog will appear to show the progress of the update. This operation cannot be cancelled. The option to update multiple forms simultaneously is not available in InfoPath 2010 and 2013.
The InfoPath workspace is divided into two main areas: the form area and the task pane area. By default, the form area appears on the left side of the screen and the task pane area appears on the right.
Figure 6: The InfoPath 2010 Workspace
The Form Area
The form area is the large open area on the left side of the InfoPath workspace. When a form is open, it appears here. This is the area where users type information into a form or design a form. The form area also allows users to see the results of actions performed from a menu, toolbar, or task pane.
The Task Pane
The task pane area provides tools for most of the actions that you need to perform in InfoPath. By default, it is docked on the right side of the InfoPath application window, but it can also dock to the left side of the application window.
The Task Pane in InfoPath 2007
You can switch between the various task panes by using the drop-down list at the top of task pane area. The task panes can also be hidden if necessary. The Task Pane command on the View menu (or CTRL + F1) toggles the visibility of the task pane area.
The Task Pane in InfoPath 2010 and 2013
Much of the functionality that used to be found in the task pane in previous versions of InfoPath has been moved to the Ribbon at the top of the application window. By default, only the Fields task pane is still found in the task pane window. However, some of the other task pane functionality can still be opened in the task pane window as well.
Views Task Pane (InfoPath 2007 only)
Figure 7 Views Task Pane
A view in InfoPath is an HTML representation of the XML data in the form. It is produced by applying an XSL transform to the XML data to produce HTML. Because views are separate from the actual data, you can create multiple views of the same data and changes to the data made in one view will automatically be applied to the others. Since the transforms that produce InfoPath views produce standard HTML, you can use the transform to produce a read-only view of the data even if InfoPath is not installed. (You can also use a “browser-enabled” form to create either a “read-only” view or a “read/write” view for users that do not have InfoPath. For additional information on browser-enabled forms, see the InfoPath Forms Services section.)
To add a new view to a form, simply click Add a New View… in the Views task pane. If a form has multiple views, you can specify which view you want to use as the default by right-clicking the view and clicking Set as Default on the shortcut menu. You can delete a view by clicking Delete on the context menu.
Fields Task Pane
Figure 8: The Fields Task Pane
The Fields task pane, called the Data Source task pane in InfoPath 2007, allows you to view and work with the XML Schema that defines the form. The fields of the schema are displayed in a tree structure, along with an icon indicating their type.
Types of Fields
Three types of fields are available in the Data Source task pane, corresponding to the three types of fields in an XML document. All three field types provide the opportunity to modify their behavior and validate the data they contain through the Changing, Validating, and Changed events, discussed in the InfoPath Events and the Programming Environment section of this document. The three types are Groups, Elements and Attributes.
Groups in the data source correspond to elements of an XML document that have child elements. An InfoPath form must have at least one group field to serve as the root of the schema. Groups can occur singly, or they can repeat.
Elements in the data source correspond to leaf elements of an XML document—elements that have no child elements. Elements can still have attribute children. Elements, which InfoPath also refers to as field (element) and element (field) are assigned a data type and you can give them a default value. You can also specify that they cannot be blank. Like groups, elements can occur singly or they can repeat.
Attributes, which InfoPath also refers to as field (attribute) and attribute (field) in the data source, correspond to attributes of an XML element. Like attributes of an XML element, attributes cannot repeat. However, you can specify that an attribute cannot be blank. Like elements, attributes have a data type and can also have a default value.
A Note on Data Types
In addition to the data types that are built into InfoPath, you can define your own data types in the XML Schema, and InfoPath will honor them. This can be useful, for example, if you need a data type with specific constraints. InfoPath will use the constraints of the data type when performing data validation. For example, the following schema fragment produces an “AmtType” data type that can contain a maximum of 18 digits:
<xs:fractionDigits value="10" />
<xs:totalDigits value="18" />
Elements and Attributes in an InfoPath form can be assigned a default value. This default value can be a static value, or it can be function or formula. This is useful if you wish to specify that the default value of a field is dependent on the value of one or more fields in the form or the current system date or time.
Additionally, if the default value is the result of a formula, you can specify that the value be kept updated as the values of the arguments in the formula change. This allows you to create calculated values that are maintained as the form is updated.
Figure 9: Insert Formula dialog
To specify a static value, key the value directly into the Value field of the Properties dialog. To specify a calculated value, click the Formula button (“fx”) beside the Value field to launch the Insert Formula dialog. After verifying the formula, click the OK button to dismiss the Insert Formula dialog. The formula will show in the Value field of the Properties dialog.
Note: The formula is treated as an atomic element and cannot be edited directly in the Value text box. Any modification must be made by re-launching the Insert Formula dialog
To specify that the calculated value be kept updated as the values of the arguments in the formula change, check the Update this value when the result of the formula is recalculated checkbox. This will not prevent users from entering values directly in any controls bound to this field; you may wish to set the Read Only property of these controls to True to prevent data conflicts.
Controls Task Pane
InfoPath uses simple controls for the display and modification of data in a form, including controls for fields, groups of fields, and repeating groups of fields. The Controls task pane provides access to the controls.
The Controls Task Pane in InfoPath 2007
The Controls task pane in InfoPath 2007 is organized into 5 categories of controls: Standard, Repeating and Optional, File and Picture, Advanced and Custom. Form designers may add new or existing ActiveX controls or Template Parts to the Custom category. (For additional information on custom controls see the Extending the InfoPath Control Set with Custom ActiveX Controls section.)
Figure 10 Controls Task Pane in InfoPath 2007
The Controls Task Pane in InfoPath 2010 and 2013
In InfoPath 2010 and 2013, controls are normally displayed on the Home ribbon, but you can also display the Controls task pane by clicking the Controls Pane button on the ribbon.
The Controls task pane provides access to the controls and is organized into four categories of controls: Input, Objects, Containers, and Custom. Form designers may add new or existing ActiveX controls or Template Parts to the Custom category. (For additional information on custom controls see the Extending the InfoPath Control Set with Custom ActiveX Controls section.)
Figure 11 Controls Task Pane in InfoPath 2010 and 2013
The standard input controls are the most commonly used controls in a form. They include the types of controls where the user enters data into the form, like Text Boxes and List Boxes.
Text Boxes and Rich Text Boxes
Text boxes are used to display generic data in a form. A text box can display data of any type. Rich text boxes are used to display Extensible Hypertext Markup Language (XHTML) data. Text boxes and rich text boxes provide the ability to check spelling and perform auto-completion. Form designers can also control the alignment of the text, as well as how text wraps and scrolls when the length of the text exceeds the width of the text box and whether focus is automatically moved to the next control when the length of the text entered matches the text limit specified. This is especially useful for data entry purposes where the user enters data such as zip codes, phone numbers, etc.
Figure 12: Setting Display attributes from Text Box Properties box
By enabling the Multi-line/Paragraph breaks attribute, the text box will accept carriage returns instead of ignoring them. It is important to note that carriage returns are considered whitespace, and not all XML parsers will honor them. For this reason, it is usually preferable to avoid them whenever possible.
Another feature of text boxes is the ability to align the text with surrounding text and labels. For example, when removing the border from a text control the surrounding text may become vertically offset. To re-align this text, in the Text Box Properties dialog choose the Size tab and click the Align button.
Linked images in Rich Text controls
In addition to embedding images in Rich Text controls you can enable linked images, which will embed a link to the picture in the XML instead of base64 encoding the picture in the XML. When linking to an image, the underlying “src” attribute in the XML contains only the path to the selected picture. Linked images are also supported for web enabled InfoPath forms.
List Boxes, Drop-Down List Boxes
List boxes and drop-down list boxes allow the user to choose a value from a list of available choices. The choices can be specified through a manual list of Value/Display Name pairs in the List Box Properties dialog box, they can be drawn from a secondary data source (e.g. values in form data), or they may be drawn from values in a data connection to a database, Web service, XML file or SharePoint library or list.
The Combo-box control was added was to allow InfoPath to have controls that map directly to as many SharePoint controls as possible. Although the combo-box control is very similar to the drop-down list box, the combo-box allows users to enter a custom value or to choose a value from a pre-determined list.
Check boxes can indicate whether a particular condition in the form is on or off. Typically, they are used to present a true/false or yes/no choice to the user, but InfoPath allows you to specify the value entered in the XML file when a check box is cleared and when it is checked. This value defaults to a Boolean, but you can specify another data type if you want. You can also specify the default state of the check box.
Option (Radio) Buttons
Like list boxes, option buttons allow the user to choose a value for a field from a set of available choices. Unlike list boxes, the choices must be specified manually by setting the Value when selected property of each option button in the set. All of the option buttons in a group are bound to the same field. If multiple option buttons have the same value when selected, they will toggle on or off together. In other words, toggling one automatically toggles the other.
Date pickers provide a calendar-style interface from which users can choose a date to enter into a field.
Figure 13: Choice Group with two Choice SectionsMultiple Selection List Boxes
The Multiple Selection List Box control allows a user to select one or more items from the list. The options available as a data source for this control are the same as List box, Drop-down box or Combo-box control. The field (node) that this control is bound to must be “repeating” as items that get selected are automatically added to that repeating node.
Just like groups, individual elements can repeat. Most data types are displayed in repeating tables. To display repeating text elements, InfoPath provides lists. You can use plain, bulleted, or numbered style lists. Unless the list is marked Read-only, carriage returns in the list automatically add a new element to list.
Person/Group Picker (InfoPath 2010 and 2013)
Figure 14: The People/Group Picker Control InfoPath 2007 allowed you to add a Contact Selector control to your InfoPath forms using a custom ActiveX control, but InfoPath 2010 includes a people picker control as a built-in, first class control. The people picker control communicates with SharePoint to search for a people and groups.
External Item Picker (InfoPath 2010 and 2013)
Through its Business Data Connectivity Services, SharePoint 2010 adds the ability to easily connect to external data sources like SQL Server, WCF web services, and managed code data providers. The External Item Picker control allows you to surface this data in your InfoPath form.
Figure 15 The External Item Picker Control
Controls in the objects section include controls that allow the user to insert objects and metadata into a form. These include buttons, pictures, and calculated values.
Buttons allow you to create special functionality in the form by using Rules or writing script to handle the OnClick event of the button. You can edit the script for the button by clicking the Edit Form Code button in the Button Properties dialog box.
Picture Buttons (InfoPath 2010 and 2013)
Picture button controls work just like button controls, except they allow you place your own image on the button face instead of a label. You can also specify a different picture to display when the user hovers their mouse over the picture button.
Expression Box (InfoPath 2007) / Calculated Value Control (InfoPath 2010 and 2013)
XPath calculated values allow you to reference data in other parts of the form to provide additional information or to make the form more responsive to the user’s input. For example, you could use an XPath expression as shown in Figure 14 to display a sum of all the elements in a column of a repeating table.
Figure 16: Insert Calculated ValueAlmost all controls in an InfoPath form are bound to specific fields or groups in the schema. There are several ways to bind a control to a field in the data source. The Insert Formula dialog box used to define the expression can be opened by clicking the formula button.
Figure 16: Insert Caption dialog
The Vertical Label control allows you to insert text that is displayed vertically in an InfoPath form. The text and size of this control can be changed by using its control properties dialog. You cannot resize or edit the text directly. The control does not allow editing of text such as East Asian text, which are often used vertically.
File Attachment Control
This control provides a way to attach a file to the form when the form is in Fill Out a Form (edit) mode. The designer positions the control on the template. The end-user clicks the control, browses to and selects the file to attach.
Picture controls allow the user to add an image to the form. You can control whether the user is allowed to change the picture, whether a default image or a placeholder is displayed by default and if the image is embedded in the form or simply a link to the image is stored in the forms’ XML. The image can be of any type that Internet Explorer can display.
Ink Picture Controls
Ink Picture controls allow signatures and drawings to be included in a form. It adds a blank region to the form; when a user is filling out the form on a Tablet PC the user can ink in the control. The ink data is stored as strokes (as binary data encoded as base64 in the XML) and can be saved and edited. Because it is a picture control there is no recognition support, but the XML is a valid GIF image and can be repurposed (e.g. on a database, ASP.NET page, etc.) for viewing in other processes. InfoPath does not support text conversion with this control. The control can have a picture image behind a written signature.
Hyperlink controls allow you to add a hyperlink to a form. Hyperlink controls allow you to specify a Link to address and a Display name. Both the Link to and Display properties can be set to a static value or drawn from another data field on the form.
Ink Entry and Ink Drawing and Writing controls
In addition to Ink Picture Controls InfoPath provides Ink Entry and Ink Drawing and Writing controls. These features are controlled through menu choices and/or by using the Ink Drawing and Writing button on the Tablet PC toolbar.
End users with a Tablet PC can fill out fields on a form in ink using Ink Entry. This feature allows users to ink directly on a form and after a short delay (the delay time is customizable), the ink is automatically converted to text and then inserted into the text control where inking takes place. Any ink will be discarded after it has been converted to text.
Ink Drawing and Writing Areas are edit-mode sections that can be inserted within a Rich Text field which preserves the ink. That ink can also be converted to text or copied to the clipboard as text.
Signature Line Control (InfoPath 2010 and 2013)
Figure 17: The Signature Line ControlThe signature line control allows users to digitally sign sections of the form or the entire form. It provides a visual representation of the underlying digital signature that protects the data.
Controls in the Containers section include controls for organizing data into logical groups. These include sections and repeating sections.
Sections allow the child elements of the group to be laid out in a free-form un-structured fashion, similar to control layout in the main form. Sections can repeat, and you can control the default values of the elements in the added section, the menu items that are added to assist users, and whether users are allowed to add new sections.
Sections can contain groups that don’t repeat. You can also use a section to display optional groups in a form. Optional sections give you all of the options to control default values, menu commands, and user control of sections and repeating sections. In addition, optional sections allow you to choose whether the section is included in the form by default. If the section is not included by default, you can select the Show insert button and hint text check box in the Section Properties dialog box and add a placeholder for the section. Users can click the placeholder to easily add the optional section to the form.
Figure 18: Repeating Section properties dialog
Optional and Repeating Sections
Optional Sections and Repeating Sections are simply special cases of the normal Section controls. For more information on these controls, see the Sections heading.
Repeating tables are used to display repeating groups in the data source. Each element in the group is displayed in a column of the table. Nested groups are displayed as nested tables within individual columns of the table.
You can control whether users are allowed to add new rows to the table by using the Allow users to insert and delete rows check box in the Repeating Table Properties dialog box. For tables that allow new rows to be added, you can add menu items to assist the user by clicking the Customize Commands button. Commands to Insert, Insert Above, Insert Below, Remove, and Remove All can be added. You can choose which menu or menus these commands are added to, along with the name of the menu item. These menu items are context sensitive: When a user is filling out a form and the insertion point is in the repeating table, the menu items are enabled. When the insertion point is outside the table, the menu items are disabled.
Figure 19: Table Commands dialog
By default, adding a new row to the table automatically adds each of the child elements of the group to the form. You can control which elements are added when a row is inserted, as well as the default value they’re given, by clicking Edit Default Values in the Repeating Table Properties dialog box.
Scrolling regions allow display of fixed size regions with scrollbars. In the Scrolling Region Properties dialog of the scrolling region you can specify vertical or horizontal scroll behavior as well as when the scroll bars will appear: Never, Always or When Necessary.
The Horizontal Region control is used to allow the controls on the form to “flow” as the form is resized horizontally. This control was designed primarily for use with Document Information Panels, which are hosted in other Microsoft Office applications.
Repeating Recursive Section
In certain rare cases, you may need to create a form with a recursive structure, where a section contains itself. To support this, InfoPath provides the Repeating Recursive Section.
The shaded area in the top Repeating Section is the Recursive Block. It represents the position where the recursive section will insert another copy of itself.
The properties of the recursive section correspond to the same properties of an ordinary section except the fact that digital signatures are not allowed. The only property that can be set in the internal recursive block is the default value of the XML fragment for the further recursive sections inserted within the outermost instance.
If you drag a recursive data structure from the Data Source task pane onto a view, the Recursive Section is suggested by default. For example, if a group node is repeating, and has a reference to itself, when the node is dragged to the form it will be contained in the Repeating Recursive Section control. It is unnecessary to drag the recursive children of the node onto the form.
Horizontal Repeating Table
The Horizontal Repeating Table control was highly requested by our Japanese partners. In the Japanese market, it is culturally natural to build horizontal tables. For example, if a table contains “book authors”, then adding a new author in the U.S. means adding another row, and populating the metadata about the author in the columns of the added row. For the Japanese customers, a new author would be added as a column, with the metadata in the rows.
The Horizontal Repeating Table is a collection of other controls: an “Outside” table (this is a Layout table, which is used to control wrapping, scrolling and the size of the horizontal repeating table), a “Header Column” (this is a table cell with a regular layout table inside) and a Repeating Section control.
The Master/Detail control allows you to work efficiently with large amounts of data. A common scenario is showing order data. The form lists multiple orders for a particular customer in the Master Table. The detail section shows the Order Detail for only the order currently selected within the Master table.
The properties box of the Repeating Table (Master) is shown below. The Master ID attribute is a user defined value that identifies the Master control. This is useful if a view on your form has more than one Master control.
Figure 20: Repeating Table Properties
Figure 21: Repeating Section (Detail) Properties
The properties dialog for the Detail section shows its relationship to the Master table.
Choice controls let the user replace one section with another as they fill out the form. For example, a Choice control might allow the user to choose between two different address blocks: one for international and one for the US. The user selects between the available options by using the context menu of the Choice Section as seen in Figure 17. Users filling out the form can change one section into another section by selecting the Replace command.
Figure 22: Replace with … context menu from a Choice SectionBy default, a Choice Group control provides two Choice Section controls. More Choice Section controls may be added to the group. You can also use a Repeating Choice Group control to provide a repeating set of options for the user.
In addition to the built-in controls, it is possible to create custom ActiveX Controls and Template Parts for use in an InfoPath form. The Extending the InfoPath Control Set with Custom ActiveX Controls section has more information on creating custom ActiveX controls and Template Parts.
Contact Selector Control (InfoPath 2007)
By far the most common ActiveX Control added to an InfoPath 2007form is the contact selector control. This control allows a user to enter (or select) a person’s name or logon alias and then validate that user against a SharePoint user list without using code. This has been especially true in workflow scenarios where User A needs to enter in the name of User B – the next person in the workflow process.
The Contact Selector control is an ActiveX control but it is a special cased control, in that it can also be used in InfoPath browser forms.
Step 1: Add the Contact Selector control to your Controls Task Pane
From the Controls Task Pane click the Add or Remove Custom Controls link.
Click the Add button.
On the first screen of the Add Custom Control Wizard select ActiveX control and click Next
From the list of controls, choose Contact Selector and click Next.
Figure 23 Add Custom Control Wizard
Select “Don’t include a .cab file” and click Next.
For Binding Property select Value and click Next.
From the Field or group type box choose Field or group (any data type) and click Finish.
Click Close and then click OK.
Step 2: Create the data structure for the Contact Selector Control
The Contact Selector control needs to have a specific data structure to work properly – this is documented on the Items tab of the Properties screen for the control.
**IMPORTANT!** Spelling and capitalization must be exactly the same, starting with the “Person” group!
Add a non-Repeating Group named: gpContactSelector
Add a Repeating Group named: Person
Add the following 3 text fields to the Person group: DisplayName, AccountId and AccountType
Figure 24 Data Source structure for a Contact Selector Control
Step 3: Add and bind the Contact Selector control to the View
Drag the gpContactSelector Group to the View and select Contact Selector from the list of controls
Figure 25 Select Contact Selector Control
Step 4: Add a secondary data source XML file which specifies the SharePoint server
The Contact Selector control needs to know the “context” of where the user validation should occur. These steps are not necessary if you are only displaying the form in a browser from SharePoint – in this case, it uses the context of the site from where it was provisioned; however, if you are in a mixed client/browser scenario you will need to include this XML file so forms opened in the client can use this functionality.
Launch a text editor like Notepad.
Copy and paste this one-line XML:
**NOTE: Replace <servername> with the name of your server.
Save this as: Context.xml (again – naming and capitalization are important).
Add Context.xml as a Receive type Secondary Data Connection to your form template and make sure the option “Include the data as a resource file” is enabled.
Changing Properties of multiple controls
As you design an InfoPath form template, you may find it necessary to modify the properties of several controls. Rather than change the properties of each control individually, InfoPath allows you to change certain properties of multiple controls simultaneously. To change size properties of multiple controls at the same time select the controls while holding the Ctrl or the Shift key. Then right-click on one of the controls and choose Properties. A property change will apply to all the selected controls that share that property.
Layout Task Pane (InfoPath 2007)
Figure 26 Layout Task Pane
Because form views are based on HTML, there are some limitations to the way elements are laid out. Spaces and carriage returns might be ignored, and elements can be hard to align the way you want them. To help resolve this limitation, InfoPath provides the Layout task pane to easily add HTML tables for custom layouts. To add a layout table, place the insertion point where you want to insert the table, and then click the desired table style in the Layout task pane.
In addition to layout tables, InfoPath’s designer also allows you to define page breaks within a view. These page breaks will not be visible while the user fills out the form, but when the view is printed, it will be broken into multiple pages. The Insert menu also lets the designer insert a page break for the printed form.
Design Checker Task Pane
Figure 27: Design Checker Task PaneThe Design Checker task pane allows you to:
Find compatibility problems that may exist in your form template. In some cases, InfoPath automatically fixes the problem for you and notifies you of that fix. In other cases, you will have to fix the problem manually. For example, to successfully publish a browser-compatible form template, you may need to remove an unsupported control or replace it with a different control. If you are publishing a browser-compatible form template, you can also choose to display server-related information in the Design Checker task pane.
Change the compatibility setting for the form template. For example, suppose that only users who have InfoPath installed on their computers can display and fill out forms that are based on your form template. If you want your form template to work in a Web browser as well, you can click Change Compatibility Settings in the Design Checker task pane to access options for creating a browser-compatible form template instead of an InfoPath-only form template. When you change the compatibility setting for a form template, the errors and messages in the Design Checker task pane update accordingly.
For more information on the Design Checker see the Design Checker Task Pane section.
Like the other applications in the Office family, InfoPath 2010 supports the Ribbon interface. The ribbon is designed to collect commands and tasks into functional groups which can change based on the user’s activity. Much of InfoPath’s form design functionality is now found there.
Page Design Ribbon
Figure 28: The Page Design Ribbon
The Page Design ribbon is used to work with views in InfoPath. A view in InfoPath is an HTML representation of the XML data in the form. It is produced by applying an XSL transform to the XML data to produce HTML. Because views are separate from the actual data, you can create multiple views of the same data and changes to the data made in one view will automatically be applied to the others. Since the transforms that produce InfoPath views produce standard HTML, you can use the transform to produce a read-only view of the data even if InfoPath is not installed. (You can also use a “browser-enabled” form to create either a “read-only” view or a “read/write” view for users that do not have InfoPath. For additional information on browser-enabled forms, see the InfoPath Forms Services section.)
To add a new view to a form, simply click New View on the Page Design ribbon. If a form has multiple views, you can select which view to work with using the Current View dropdown list, and you can edit the properties of the current view by clicking Properties. You can delete a view by clicking Delete on the Page Design ribbon.
Figure 29: The Data RibbonThe Data ribbon allows you to work with the data sources that are connected to the form template. These include Form Data, data connections that Get External Data, data connections that Submit the Form, as well as Rules and Roles for manipulating form data.
InfoPath Form Template Component Files
An InfoPath form template is made up of a collection of component files compressed into a CAB format file with an .xsn file extension. Normally, it is fine to leave the files in this format and work with them indirectly through InfoPath’s design mode. However, there may be times when it is useful to access some of the component pieces of a form template. InfoPath 2007provides the capability to export these component files by using the Save As Source Files command on the File menu. In InfoPath 2010 and 2013, this command has been moved to the Publish tab of the File menu, where it has been renamed Export Source Files.
The Form Definition File
The form definition file, usually named manifest.xsf, is an XML file that contains the information InfoPath needs to construct a form from the various XML, XSL transform, and script files in the form template. The form definition file contains, among other things, a list of all the files that make up the form template and their properties, a list of all the views in the form template and their editing options and special menu items, and information concerning the data sources that are accessed by the form. The form definition file format is documented in the InfoPath Developer’s Reference, which can be found in the InfoPath Help system (
http://officebeta.iponet.net/client/helpcategory.aspx?CategoryID=CH101129901033&ns=MSE&lcid=1033InfoPath Developer Reference >
http://officebeta.iponet.net/client/helpcategory.aspx?CategoryID=CH101080471033&ns=MSE&lcid=1033Form Template Components.)
The schemas that InfoPath uses to define the data source structure are stored as XML Schema (.xsd) files in the form template. The schema of the form data itself, as well as the schemas of any secondary data sources, can be found here. Depending on the complexity of a schema, it may be stored in a single file, or it may be stored in multiple files and referenced with <xsd:import> tags.
The form template contains a file usually named template.xml, which is used as the basis for new forms. Template.xml is where default values for a form are stored, and it contains all of the namespaces and XML processing instructions for the form as well. Changes to this file will be reflected in all subsequent forms created from the form template.
Similar to the template file, a form template also contains a file usually named sampledata.xml, which contains an example of the raw XML data produced by the form. It is different from template.xml in that it doesn’t contain InfoPath-specific XML processing instructions. This can be useful as sample data for testing transforms.
The XSL transforms that produce the various views in an InfoPath form are also stored within the form template.
If a form template makes use of script (specifically VBScript or Jscript) to provide custom functionality or data validation, this is stored as a separate file. Depending on the language that the script is written in, this file is usually called script.js or script.vbs. Like all the other files in the form template, this is a text file that can be edited if necessary.
Script Deprecated in InfoPath 2010 and 2013
The use of unmanaged script in InfoPath forms has been deprecated in InfoPath 2010 and 2013, because unmanaged code is not supported in browser-compatible forms, and because it does not provide the same level of code security that is available in managed code. Existing forms with unmanaged script will still run, but you cannot create new form templates with unmanaged script.
When the form designer uses the InfoPath Visual Studio plug-in or Visual Studio Tools for Applications (VSTA) to create managed code as the code behind the InfoPath form, the published form encapsulates the .dll and .pdb files into the .xsn file. By default these files will have the same name as the form template. (For additional information on using Visual Studio or VSTA see the InfoPath Events and the Programming Environment section.)Note: The managed code project files are stored in a location of your choice; however, the default setting is: %userprofile%\My Documents\InfoPath Projects.
A Note on File Names
Although the files in the form template have default names, the names may vary. InfoPath may assign different names to various files, and you can change the file names if you choose. If you decide to make changes to the file names for any reason, take special care to ensure that you change all occurrences of the name. Many of the files in an InfoPath form template cross reference each other, and failing to locate and correct all of these cross references can result in your form template failing to work properly. It is a good idea to make a backup copy of your form template before making changes, just in case you make a mistake. In general, changing file names is not recommended.
Designing a New Form Template
Before you can fill out a form, you must first design the form template. In this process, you specify the structure you want your form’s data to have, as well as any formatting and validation you wish to use.
Designing a New Form Template in InfoPath 2007
When you start designing a form in InfoPath 2007, you will see the Design a Form Template dialog. This dialog contains all of the options for selecting the kind of form template you wish to create.
Figure 30 Design a Form Template Dialog
The Design a Form Template dialog offers a number of different form template types to create from. The form developer selects a type of form template to create, and then clicks the OK button.
Designing a New Form Template in InfoPath 2010 and 2013
When you first start the InfoPath Designer, you will see the InfoPath Backstage. The backstage contains all the commands needed to design a new form template or open an existing form template for editing. You can also access the general InfoPath Designer options from the backstage.
Figure 31: InfoPath 2010 Form Designer Backstage
The InfoPath 2010 Designer offers a number of different form template types to create from. The form developer selects a type of form template to create, and then clicks the Design Form button
Form Template Types
InfoPath offers several different types of form templates for designers to choose from. Each type offers special functionality for different scenarios. InfoPath 2010 and 2013 also add additional template types that were not originally available in InfoPath 2007.
Form Template types available in InfoPath 2007
Blank form templates are the most basic type of template. These form templates allow the user to design the data structure and views of the form without pre-set options.
XML or Schema based form templates allow you to design an InfoPath form template that complies with an existing data structure format. This can be useful when creating forms to integrate with existing business processes.
Web Service form templates are designed to query data from and/or submit data to SOAP (Simple Object Access Protocol) web services. The data structure of the form is prepopulated with the XML data structure specified by the web service.
Database form templates are designed to query data from and/or submit data to a table or tables in a SQL Server or Access database. The data structure of the form is prepopulated, and special configuration settings are included in the XSN to allow InfoPath to read and write to the database.
Connection Library form templates allow you to specify the web service or XML data from which your form templates is designed in a Data Connection library in SharePoint. This can be useful in designing multiple form templates from the same data source.
By default, form templates designed in InfoPath 2007 are designed to function only in the InfoPath client application. However, by checking the Enable browser-compatible features only option, you can design a form template that can also be published to a Microsoft SharePoint site and filled out in the browser using InfoPath Form Services. For more information about this option, see the InfoPath Forms Services section.
Form Template types available in InfoPath 2010 and 2013
Many of the available form template types in InfoPath 2010 and 2013 are directly comparable to types in InfoPath.
SharePoint Form Library and Blank Form form templates are comparable to browser enabled form templates in InfoPath 2007.
Blank Form (InfoPath Filler) is comparable to a client-only form template in InfoPath 2007.
Web Service, Database, and XML or Schema form templates are directly comparable to their InfoPath 2007counterparts.
Data Connection File form templates are comparable to Connection Library form templates in InfoPath.
New types in InfoPath 2010 and 2013
InfoPath 2010 and 2013 do offer a few new form template types.
The SharePoint List form template type creates an InfoPath form template that is directly connected to a SharePoint list. You can create a new SharePoint list or customize an existing SharePoint list. You can create new columns for the list, and InfoPath supports all of the SharePoint column types except External Data and Managed metadata. When you publish this form template, it will be used by SharePoint to add and edit list items. This template type can only connect to SharePoint 2010 and 2013 lists. SharePoint 2007 is not supported.
The E-mail form template type creates a form template that can be distributed and submitted through e-mail. This template type provides a shortcut for creating form templates you intend to publish through email.
The Document Information Panel form template type allows you to create a Document Information Panel for an existing SharePoint document library or site content type. This form template type offers a way to start the process of creating a DIP from within InfoPath 2010 and 2013.
Creating a New Blank Form
When you create a new blank form, InfoPath opens a single blank form area and makes it the default view. You can design the XML Schema for the form first, or you can create views for a form manually and let InfoPath automatically generate the schema for you. You can switch between designing views and designing the data source as needed.
Designing the View
The easiest way to create a new InfoPath form is to design the default view for your form and let InfoPath manage the creation of the corresponding data source. To add controls to your form, select the controls you’d like to use from the Home ribbon (InfoPath 2010 and 2013) or from the Controls task pane. Drag and drop the controls you want to use in your form onto the view. By default, InfoPath automatically adds fields and groups to the XML Schema shown in the Data Source or Fields task pane to correspond with the controls you add to the view. If you prefer to select the field or group to bind to a control, clear the Automatically create data source check box at the bottom of the Controls task pane.
Figure 32: Controls Task Pane
Designing the XML Schema
If you have a specific data structure in mind, it might be easier to design the XML Schema of a form yourself instead of letting InfoPath handle it. To view the data source in InfoPath 2007, open the Data Source task pane by choosing Data Source… from the View menu. To view the data source in InfoPath 2010 and 2013, open the Fields task pane by clicking Show Fields on the Data ribbon.
Figure 33: Fields Task PaneAdding a Field or Group
To add fields or groups to the schema from the Fields task pane, right-click the field or group to which you want to add a field, and then click Add on the shortcut menu.
Figure 34 Add Field or Group
In the Add Field or Group dialog box that appears, enter the field or group's name, its data type, and other related information. When you click OK, the field or group appears in the Fields task pane. When a field or group exists in the data source, right-clicking that field or group allows you to delete it or edit its properties.
Referencing an Existing Field or Group
Referencing an existing field or group creates an exact copy of it in another location in the data source. The properties of the referenced fields are bound together, so changes to the properties of one automatically change the other. When the form is being filled out, each of the referenced fields has its own value.
Figure 35 Reference Field or Group
To reference a field or group, right-click the field or group you want to duplicate, and then click Reference on the shortcut menu. In the Reference Field or Group dialog box, select a group to contain the new reference field. Note that a group cannot contain more than one reference to a field or group.
Moving a Field or Group
When designing the data source for your form, you may determine that a field or group would serve better in a different location. InfoPath allows you to move fields and groups within your data source.
Figure 36 Move Field or Group
To move a field or group, right-click the field or group you want to move and then click Move on the shortcut menu. In the Move Field or Group dialog box, select a new location for the field or group.
Note that if a control is bound to a field or group, restrictions are placed on where the field or group can be moved:
If the field or group is moved into a repeating group, the control bound to the field or group should be part of a repeating table or repeating section.
If the field or group is moved out of a repeating group, the control bound to the field or group should not be part of a repeating table or repeating section.
If the field or group is moved into a group that is bound to an optional section, make sure that the control bound to the field or group is part of the optional section.
If the field or group is moved out of a group that is bound to an optional section, make sure that the control bound to the field or group is not part of the optional section.
Creating a new form from a Data Source
InfoPath provides the ability to create a new form by basing it on an existing XML document or an external data source. You can create a form based on an XML Schema or XML data file, a SQL Server or Access database, a Web service, or a pre-defined data connection in an Office Server Data Connection Library. InfoPath 2010 and 2013 also adds the ability to create an InfoPath form for a SharePoint list.
Starting from an XML Schema
Often you’ll want to create forms to interface with existing data sources that use specific XML Schemas for their data. XML Schema (.xsd) is a World Wide Web Consortium (W3C) industry standard specification for defining the content of XML documents. Even when not submitting to a data source, an XML Schema can be used within other Office applications (Word and Excel, in particular). By using the same XML Schema to design Word documents, Excel spreadsheets, and InfoPath forms, you can load, analyze, and edit the same XML data in any of these applications and be sure that data will still be valid in the other applications.
You may want to use an XML Schema that has been standardized by a committee or another company, which may reside on a Web site somewhere on the World Wide Web. If you start from such a schema, InfoPath will download this schema and any schemas it is dependent on into your form and work from this copy of the schema. This way, users can work with your form when they are offline or when the Web site the schema resides on is not available. Note that this means that any updates to the original schema will not be reflected in the InfoPath form.
When you create a new form from an XML Schema, InfoPath will populate the Fields task pane with a representation of the schema you started from. You can then start inserting controls on the view that are connected (or bound) to your schema. InfoPath will suggest controls based on the data types of elements and attributes in your XML Schema. For instance, InfoPath will bind a date picker control to an element or attribute of type <xsd:date> by default.
A Note on Field Names
You must be careful with the names you give fields in schemas to be used by InfoPath forms. If fields have the same name, even if they are located in different parts of the schema, they can cause conflicts in InfoPath. For example, the following schema fragment can cause problems because the element “day” is referenced in both the “startWeek” element and the “endWeek” element. In a form created from this schema, changing the value of one “day” element in the form will automatically change the value of the other “day” element, which is probably not what is intended.
<xsd:element name = "startWeek">
<xsd:element ref = "day"/>
<xsd:element name = "endWeek">
<xsd:element name = "day">
<xsd:restriction base = "xsd:integer">
<xsd:maxInclusive value = "31"/>
<xsd:minInclusive value = "1"/>
The better approach would be to declare a “day” type, and then have a “startDay” and “endDay” element of that type, as shown here:
<xsd:element name="startDay" type= "day"/>
<xsd:element name="endDay" type= "day"/>
Starting from an XML Data File
There may be times when you have an XML file that is representative of the forms you want, but you do not have an XML Schema that defines the structure of that file. Nevertheless, you may still wish to design a form that will produce XML that is similar to the sample file. For this scenario, InfoPath allows you to design a form based on an XML file.
When you start from an XML document, InfoPath infers a schema from the given XML, based on the following rules:
All schema elements will be defined globally. This means that nodes with the same namespace Uniform Resource Identifier (URI) and local name will be inferred as the same node in the schema.
All schema elements will be optional.
InfoPath will leverage all available type information. If <xsi:type> is used with any intrinsic schema type, the schema element will be inferred with that type. If <dt:type> is used with any intrinsic XDR type, the XDR type will be converted into a schema type and then applied to the element. Any leaf node without type information will be inferred with type <xsd:string>.
Repeating XML nodes will be inferred with maxOccurs = "unbounded".
By creating a new form from an XML file, InfoPath will populate the Fields task pane with a representation of the inferred schema. To allow for the possibility that the XML file might not contain all the possible elements you want, InfoPath allows you to add or remove new fields or groups to the inferred schema. Any new fields or groups will be added in a new namespace URI. Starting from certain schema files can also expose this functionality.
In addition to inferring a schema from the structure of the sample XML file, InfoPath offers you the opportunity to use the values in the sample XML file as the default values of the form. This can save some time assigning default values to fields individually.
Creating a form using an XML Schema or XML data file
To create a new form from an existing XML Schema or XML data file, click XML or Schema in the New tab of the InfoPath Backstage screen, and then click Design Form. On the first page of the Data Connection Wizard, enter the full path to or click Browse to select the XML document or schema you intend to use, and click Next.
Figure 37: Select XML document or schema
On the Wizard’s next page respond to the question “Do you want to add another XML Schema or XML document to the main data source?” The default option is No. Accept it and click Finish, or opt Yes, click Next and add the location for the additional XML or XSD (schema) file.
Starting from a Database
An InfoPath form can draw its data directly from a database table, select query (or view) and display it with the same forms engine used for XML data files. Changes to the data can also be submitted back to the database, which must be either a SQL Server database or an Access database.
To create a new form from a database, select Database in the New tab of the InfoPath Backstage screen, and then click Design Form. On the first page of the Data Connection Wizard, click Select Database, and then choose an existing Data Source from the list or create a new connection to a database using the New Source button.
If the database you select contains multiple tables or queries, you’ll be prompted to select a table to use as the data source. You must select one table or query from the data source to begin.
Figure 38: Select Table Dialog showing existing Queries and Tables
Later you can select additional tables or queries that are related to the first table.
After you’ve selected a table or query, the wizard allows you to select the fields you want to use in the Data source structure list in the Data Connection Wizard. By default, all the fields of the table are selected, but you can remove fields if they aren’t necessary for your form. You can also control how the records returned from the table are sorted, and whether multiple records are allowed. To do so, click Modify Table, and then select up to three sorting criteria in the Sort Order dialog box.
Figure 39: Data Source from database
When you are done constructing the data source for your form, click Next. The Data Connection Wizard asks you to “Enter a name for this data connection”, replacing the default name “Main Connection.” In addition, if InfoPath detects that it can submit to the database, this option is automatically enabled and a text box with the submit connection name is also displayed. As with the data connection name, the submit connection name can be changed as well.
Figure 40: A new form from a Database The form area (also called the canvas) opens with three tables and two buttons. At the top is an empty “Table with Title.” Next is a “New Record” button, then an empty table intended for displaying one or more query fields from the queryFields. Next is a “Run Query” button, and last is another empty table intended for displaying the dataFields of the form and their containing controls. The actual use of the empty tables is at the discretion of the designer.
InfoPath also allows you to draw data from multiple tables or queries at the same time. In this scenario, all of the tables or queries must have a relationship with their parent table. For example, if you were drawing data from the Customers table of the Northwind database, you could add the Orders table to retrieve data about all the orders for that customer, and you could add the Order Details table to retrieve the details of each order.
To add an additional table to the data source, in the Data Connection Wizard select the table to which you want to add a child table in the Data source structure list, and then click Add Table…. In the Add Table or Query dialog box, choose the table or query you wish to add, and then click Next.
In the Edit Relationship dialog box, InfoPath prompts you to select the relationship or relationships you want to use. If fields in the two tables have the same name, InfoPath automatically adds those fields as a relationship, but if not, or if you wish to use a custom relationship, you can click Add Relationship to specify which fields in the parent table correspond to fields in the child table. You can also remove existing relationships by clicking Remove Relationship. When you’re satisfied with the relationships, click Finish.
Figure 41: Define the relationships between multiple tables
Just as with the main table, you can specify which fields are returned from the child table. When you have added child tables to the Data Source you can use the Modify Table button to edit the order in which the records are returned from only one table.
Custom SQL Queries
In some cases, you might need to customize the query InfoPath uses to retrieve the data. You do this by clicking Edit SQL on the second page of the Data Source Setup Wizard. This opens the Edit SQL dialog box and displays the SQL statement that InfoPath constructed from your selection of tables and fields in the wizard. Make any necessary modifications, and then click Test SQL Statement to make sure the SQL statement is functional and provides enough information for InfoPath to extrapolate an XML Schema for the data. When you’re satisfied, click OK to save the changes.
Figure 42: Edit the SQL statement InfoPath uses to query the database
Note that the SQL statements used by InfoPath are data shaping queries. Data shaping queries allow the building of hierarchical relationships between two or more logical entities in a query. For more information on data shaping queries, see the following Knowledge Base article:
How To Use the ADO SHAPE Command
Submitting to a Database
In addition to receiving data from a database, InfoPath is capable of submitting new or changed data back to a database. To track changes to data in the form, InfoPath adds a special hidden xdado attribute to each field bound to a database element. It stores information about the changes to the field in this attribute. When you use the Submit command to submit changes to the database, InfoPath uses ADO to update the records in the database.
Note that InfoPath cannot always submit changes back to a database. For example, if you create a form that draws data from a query instead of a table, if you customize the SQL statement used by InfoPath to include a JOIN statement, or if you include “long” data types (i.e. Image, Binary, etc.) InfoPath will be unable to submit changes. Another situation where InfoPath cannot submit changes would be when you add tables to the form that have a many-to-one relationship with their parent table. In situations where InfoPath will be unable to submit changes to the database, the Summary section on the summary page of the Data Source Setup Wizard will display the reason for the limitation.
Starting from a Web Service
In addition to XML data files and SQL Server and Access databases, InfoPath can submit data to and retrieve data from XML Web services. Your form doesn’t have to receive and submit its data to the same Web service, which gives you a good deal of flexibility in designing your form.
To create a new form from a Web service, select Web Service in the Design a Form Template screen. On the first page of the Data Connection Setup Wizard, choose whether you want your form to receive data, submit data, or both receive and submit data, and then click Next.
Figure 43 Select whether to receive or submit data to the Web Service
Submitting Data to a Web Service
The difference between a receive-style form and a submit-style form is mainly whether you care about the response from the Web service. In a submit-style form, InfoPath creates a schema based only on the parameters of the Web service and ignores the return values. Of course, if the Web service returns a SOAP error (rather than simply a return value, such as a custom string that indicates a value), InfoPath will still notify you that the submit operation failed. Think of a submit-style form as a way to send data to a Web service without having to write low-level SOAP calls.
For forms that submit data, enter the Web service to use when submitting data from the form. You can specify the full URL to a WSDL file, or you can search a UDDI server for existing Web services that meet your needs. InfoPath will parse the WSDL file and display a list of the available methods for providing XML data to your form. Select the method you wish to use, and then click Next. Click Finish to complete the data source setup.
Receiving Data from a Web Service
In a receive-style form, both the parameters of the Web service and the return values from the Web service are important. The response from the Web service and any "out" parameters from the Web service are incorporated into the schema that InfoPath generates. Think of a receive-style form as a way to retrieve data from a Web service, again without having to write low-level SOAP calls.
For forms that receive data, enter the Web service to use when receiving data, and then click Next. You can specify the full URL to a Web Service Definition Language (WSDL) file, or you can search a Universal Description Discovery and Integration (UDDI) server for existing Web services that meet your needs. InfoPath will parse the WSDL file and display a list of the available operations for providing XML data to your form. Select the method you wish to use, and then click Next.
Figure 44: Select the Web service method to use
Receive-Submit Hybrid forms (InfoPath 2007)
A receive-and-submit-style form is a hybrid of these two styles. The schema for the form is created just as if the form were a receive-style form. Then you are given the opportunity to map the elements of that schema to the parameters of another Web service (or the same one, depending on the Web service implementation). First enter the Web service and method that will be used to receive data for the form. InfoPath will extrapolate a query/data schema structure for the form from this Web service method.
Next, enter the Web service and method that will submit data from the form. At this point, InfoPath prompts you to select the field or group from the form that will be used to fill the parameters of the Web service method. InfoPath provides several options for sending data to a web service:
Submit a field or group
Submit the text and child elements of a field or group
Xml sub-tree, including selected element
Submit the entire XML document, including processing instructions
Submit the data as a string, rather than encoded as XML
To set the parameters of the web service, select each parameter displayed in the Parameters list, and then click the Select a Field of Group icon. Browse through the query/data schema structure of the form in the Select a Field or Group dialog box and select the field or group that will be submitted for that parameter; then click OK. After mapping each parameter to a field or group, click Next. Enter a name for this submit connection and then click Finish.
Figure 45 Map the parameters of the web service to the fields in the data source
Receive-Submit Hybrid forms Deprecated in InfoPath 2010 and 2013
InfoPath 2010 has deprecated the receive-and-submit style form available in previous versions of InfoPath. Best practices for form design recommend creating a receive-style form and then adding submit functionality, so the hybrid format has been removed.
Adding Submit capabilities to a Receive-style form
After you've created your receive-style form, click Submit Options on the Data ribbon (on the Tools menu in InfoPath 2007). In the Submit Options dialog box, click Allow users to submit this form, and then click Web Service in the Send form data to a single destination list.
Figure 46: Submitting Forms dialog box
Select the web service data connection, or click Add to add a web service and method you want to submit to, and click OK. Next, enter the Web service and method that will submit data from the form. At this point, InfoPath prompts you to select the field or group from the form that will be used to fill the parameters of the Web service method. InfoPath provides several options for sending data to a web service:
Xml subtree, including selected element
To set the parameters of the web service, select each parameter displayed in the Parameters list, and then click the Select a Field of Group icon. Browse through the query/data schema structure of the form in the Select a Field or Group dialog box and select the field or group that will be submitted for that parameter; then click OK. After mapping each parameter to a field or group, click Next. Enter a name for this submit connection and then click Finish.
Web Services and ADO .NET Datasets (InfoPath 2007)
The Web services data connection allows you to easily connect to Web services that use ADO.NET Datasets to both receive and submit data. This can be useful for connecting to databases other than Microsoft SQL Server and Microsoft Access, and for protecting access to your database. Note that this feature is only available in forms running in the InfoPath client. It is not available in browser-based forms.
The integrity of the Dataset will be maintained as the user edits it. Specifically, the following will be enforced
Primary/foreign key relationships between tables of the Dataset will be enforced, where all foreign keys need to point to an existing primary key. Changes to the primary key value will be cascaded to all associated foreign keys.
Unique constraints on primary keys are enforced as the user edits them.
Read only columns
Fields which represent columns in the Dataset that are marked as read only will be respected by rejecting any modifications made to them. Such fields are specified when designing the Dataset using ADO.NET’s ReadOnly property on a DataColumn object.
In addition, values of fields that represent table columns whose values are to be automatically incremented will be automatically incremented as specified by the ADO.NET Dataset.
To design a form that connects to a Web service which uses a Dataset go to the Design a form task pane and click Web Service and follow the Data Connection Wizard to configure your Web service connection to receive data. To add a data connection to submit a Dataset, you must first setup the form to query for a Dataset as described above. The submit data connection can be added when you create the query data connection by selecting to Receive and Submit from the Web service data connection in the Data Connection Wizard. Alternatively, you can add a submit data connection using the Data Connections dialog under the Tools menu.
In the Data Connection Wizard, after selecting an operation to submit to, you can specify which fields or groups in your form provide the data for the operation’s parameters. For each submit parameter whose type is a Dataset, select the Field or group radio button, and click the XPath button to select the corresponding Dataset group from the data source.
Note: Selecting any field or group other than a Dataset group to submit a Dataset parameter will result in that parameter data being submitted as verbatim XML and not properly serialized, which will eventually cause the submit operation to fail.
Connecting to ADO .NET Dataset Web Services Deprecated in InfoPath 2010 and 2013
This feature has been deprecated in InfoPath 2010 and 2013 because it does not work in forms designed for the browser, and does not handle many cases with complex data structures. Existing form templates that make use of Dataset connections will still work as expected, but no new forms will contain this functionality.
Changing Data Sources and Server Names
It is a common practice in developing applications to make use of test data sources and servers during the development process. When the application is ready, it is switched over to a production data source or server. To achieve this in Microsoft Office InfoPath, you can use the Convert Main Data Source command on the Tools menu. This command launches the same Data Connection Wizard used to create the form template, and allows converting the current data source while retaining the information that depends on it. The data source structure must be similar to that used when first designing the form.
Once the new data source is chosen, all the dependent data and controls in the form template will be mapped to the new data source. When this is not possible (e.g. because a field was removed and no new one is substituting it), controls may appear unbound in the view.
Data Connection Library
In addition to the methods described above, if you are using Microsoft Office SharePoint, you can create a Data Connection Library to store data connection files. A data connection file is an XML file with either a .udcx or .odc file extension that contains connection information for a single external data source. The files are created by the developer and stored in a data connection library in SharePoint. To use settings from a data connection file in InfoPath, the data connection file must follow the Universal Data Connection version 2.0 file format.
The data connection file is used by InfoPath to create the data connection to the external data source referenced in the file. Advantages of using a data connection file include:
Multiple form templates can share the same data connection file.
If the external data source changes, you only need to update the data connection file rather than updating each form template.
The data connection file can contain alternative authentication information to be used by the server when the user fills out a form in a Web browser.
When a user opens a form based on the form template and it uses a data connection file, InfoPath uses the settings in the data connection file.
The following is a sample UDCX file that retrieves the CustomerID and CompanyName fields from the SQL Server Northwind Customers table via a web service method named: GetCustomers:
<?xml version="1.0" encoding="UTF-8" ?>
<udc:DataSource MajorVersion="2" MinorVersion="0" xmlns:udc="http://schemas.microsoft.com/office/infopath/2006/udc">
<udc:Description>Format: UDC V2; Connection Type: WebService; Purpose: ReadOnly; Generated by Microsoft Office InfoPath 2010 on 2006-05-04 at 15:43:24 by NORTHAMERICA\sheim.</udc:Description>
<udc:Type MajorVersion="2" MinorVersion="0" Type="WebService">
<udc:SubType MajorVersion="0" MinorVersion="0" Type="" />
<udc:ConnectionInfo Purpose="ReadOnly" AltDataSource=""> <udc:WsdlUrl>http://servername/WebServices/NWTables/NWTables.asmx?WSDL</udc:WsdlUrl>
<udc:ServiceUrl UseFormsServiceProxy="false" />
<udc:FileName>Specify a filename or formula</udc:FileName>
<udc:FolderName AllowOverwrite="" />
<!-- udc:Authentication> <udc:SSO AppId='' CredentialType='' /></udc:Authentication -->
If you created your InfoPath form from the connection files in the Data Connection Library you would only need to modify the UDCX files in the Data Connection Library to now point to the production data source or server.
Starting from a Connection Library
To create a new form from a data connection file, click Connection Library in the Design a Form Template screen. From the Site drop-down box, select the Server that contains the connection files.
Figure 47:Select Data Connection Library Server
NOTE: If there are no servers listed click the Manage Sites button to add the server to this list.
Once you select the server that contains the Data Connection Library you will see a list of the available connections.
Figure 48: Select a connection
Select the connection that you need and click Next.
By default, the Data Connection Wizard will use the name of the connection file as the name for the data connection in InfoPath. If you would prefer to use a different name, enter it here and click Finish.
Figure 49 Specify a name for this connection
InfoPath provide import converters for Microsoft Office Word and Microsoft Office Excel to allow conversion of Word documents and templates and Excel spreadsheets and templates to an InfoPath form template. The import process will import the view of the data, infer a schema based on the existing fields in the document and add appropriate controls.
Importing Excel forms
Many organizations use Microsoft Office Excel workbooks as forms to collect data. These workbooks usually include blank cells for users to enter data. You can convert a workbook to a Microsoft Office InfoPath form template by using the Import Wizard in InfoPath. By converting a workbook to a form template, users can benefit from InfoPath features such as schema validation, dynamic controls such as repeating sections, and business logic such as data validation. In addition, an InfoPath form template can be made available to a wider audience by creating a browser-compatible form template. (For additional information on creating a browser- compatible form template see the InfoPath Forms Services section.)
When you convert an Excel workbook to an InfoPath form template by using the default settings in the Import Wizard, the resulting form template contains the layout of the Excel workbook. In addition, cells in the Excel workbook that meet certain conditions are automatically converted to text box controls that users can enter data into. For example, if a cell is formatted to show a border on all sides, that cell is converted to a text box control in the resulting form template. If you decide not to use the default setting in the Import Wizard, you can choose to include only the layout when you import the Excel workbook or to convert only certain types of cells to controls.
Figure 50 Excel import options
During the conversion process the workbook is used like a blueprint to create a new form template. The table structure of the workbook is recreated as a layout in the form template. If you choose to include cells that are used to collect data when you convert the workbook, text box controls are added to the form template in the layout table cells that correspond to the location of the fields in the workbook. The size and position of supported cells, cell borders and shading, and whether cells are merged or split are preserved in the resulting form template.
If your workbook contains several worksheets, the data and formatting on the first worksheet are added to the default view in the new form template and the additional worksheets are converted to corresponding views in the form template. The titles of each additional view match the titles of the worksheets.
To import an Excel file select Import a Form from the Getting Started screen after launching InfoPath. Select InfoPath importer for Excel workbooks and click Next.
Figure 51 Import Excel Workbook
Click the Browse button, navigate to the Excel workbook to import and click Open.
Figure 52 Select Excel Workbook
To view the available import options, click the Options button, make any needed adjustments and click OK.
Figure 53 Excel Import Options
Click Finish to complete the import process.
Some settings and formatting in Excel workbooks are not supported by InfoPath. When you convert a workbook that contains such settings, the resulting InfoPath form template will not contain those features or settings. For example, if your workbook has a header that contains an image, the image will not be preserved in the resulting InfoPath form template because InfoPath does not support images in headers and footers.
The following is a list of features and settings that are not preserved when you convert an Excel workbook to an InfoPath form template:
Cells with "shrink to fit" formatting
Cell background images
Cell background patterns
Print settings (including A4 paper resizing, black and white, center on page, first page number, page order, pictures, print gridlines, print quality, row and column headings, rows and columns on every page, scaling, and set print area)
Vertical text alignment
Rows that are narrower than the default font height of 10pt
The following list explains the features and settings that are partially supported when you convert an Excel workbook to an InfoPath form template:
Cells with data formatting: Styles or colors applied to cells with data formatting are not converted. For example, if a cell is formatted to display negative numbers as red text, the number value is converted, but the red text formatting is not.
Hyperlinks that reference unsupported protocols: All hyperlinks are converted, but if the hyperlink uses a protocol other than http:, https:, ftp:, or mailto:, the hyperlink will not work when a user clicks the link.
Header and footer alignment and formatting: A header or footer in an Excel workbook can contain a left, middle, and right section. These are concatenated upon import to InfoPath. For example, an Excel workbook with a left header containing the name "Wendy Wheeler," a middle header containing the title "Status Report" and a right header containing date "October 13," would be converted to an InfoPath form template containing a single header with the following text: "Wendy WheelerStatus ReportOctober 13,." If only one section in the workbook's header or footer contains text, the resulting text in the form template will be aligned accordingly. For example, if only the right section of the header contains text in the workbook, then the corresponding text in the form template will be right aligned. Otherwise, all header or footer text is aligned left when it is imported. The font setting applied to the first header or footer section in the workbook is applied to the entire header or footer in the resulting InfoPath form template.
Font conversion: Although InfoPath imports the fonts from a workbook when creating a new form template, if the fonts in the workbook are not available on the computer where you perform the import, alternate fonts will automatically be selected for the form template.
Implicitly merged cells: In Excel, if you type more text than will fit in the current cell, the text will appear on top of the subsequent cells as if the cells had been merged. InfoPath does not support this feature. If a converted cell contains more text than the cell width can accommodate, the text will wrap to the next line in InfoPath. To prevent this, before you import your workbook, select the cell and as many subsequent cells as are necessary to contain the text, and merge the cells so that the text fits within the merged cell.
PivotTable reports: PivotTable reports are converted as layout tables.
Very large tables: InfoPath supports tables that are up to 63 columns wide and 999 rows long. If an Excel workbook exceeds these limits, only the first 63 columns and 999 rows will be converted.
Importing Word forms
Some organizations use Microsoft Office Word documents to collect data, where users typically fill out these documents by entering data in form fields, such as text boxes or drop-down lists, or by writing or typing in empty table cells or blank, underlined areas. You can convert a Word document to a Microsoft Office InfoPath form template by using the Import Wizard in InfoPath. This allows you to take advantage of dedicated features for designing, publishing, and filling out forms. You can also make your form template available to a wider audience by creating a browser-compatible form template, which users can fill out in a supported browser. (For additional information on creating a browser-compatible form template see the InfoPath Forms Services section.)
As with Excel, when you convert a Word document to an InfoPath form template the basic structure of the document is recreated as closely as possible in the form template. If you choose to include form fields when you convert the document, text box, check box, and list box controls are added to the form template at a location that corresponds to the location of the fields in the document. In addition, InfoPath automatically detects areas in the document that might work well as repeating tables and rich text boxes and converts them to the appropriate controls. For example, if an expense report document includes an empty, underlined area for users to enter notes about a particular expense, InfoPath will convert that area to a rich text box. Users can then type multiple lines of text in the rich text box, and format that text as they wish.
You can use the settings in the Import Options dialog box to change the options for importing a Microsoft Office Word document to Microsoft Office InfoPath.
Figure 54 Word import options
To import a Word document select Import a Form from the Getting Started screen after launching InfoPath. Select InfoPath importer for Word documents and click Next.
Figure 55 Import Word document
Click the Browse button, navigate to the Word document to import and click Open.
Figure 56 Select Word document
Figure 57 Word import options
Click Finish to complete the import process.
Some settings and formatting in Word documents are not supported by InfoPath. When you convert a document that contains such settings, the resulting InfoPath form template will not contain those features or settings. For example, if your document has revision marks, the revision marks will be discarded in the resulting InfoPath form template because InfoPath does not support this feature.
After importing the document you can use the Design Checker task pane in design mode to discover any problems with the conversion and then take action to correct those problems.
The following is a list of features and settings that are not preserved when you convert a Word document to an InfoPath form template:
Footnotes and endnotes
Newsletter-style column layout
Linked or embedded objects (e.g. Microsoft Office Excel worksheets and Microsoft Office Visio drawings)
Drawing objects (including AutoShapes, curves, lines, and WordArt)
Character spacing (including scaling, expanded or condensed spacing, raised or lowered positioning of text, and kerning for fonts)
Comments and tracked changes (e.g. insertions, deletions, and formatting changes)
Print settings (including mixed character formatting in headers and footers, different odd and even headers and footers, different headers and footers for first page, gutter settings, negative values for top and bottom margins, different page orientations, and individual section settings)
The following list explains the features and settings that are partially supported when you convert a Word document to an InfoPath form template:
Vertical text: If vertical text appears in a table cell in the Word document, it will be converted to a vertical text control in the resulting form template. However, if the vertical text appears outside a table, in the body of the document, it is converted to horizontal text in the form template.
Text boxes: In Word documents, text boxes are containers for text that can be positioned on a page and sized. If the document contains a text box, that text box will be converted to a table cell with a border in the resulting form template. Any text contained in the text box will appear in the table cell, but formatting on the text will be lost.
Underlined text: Underlining is supported; however, decorative or double underlining in the document is converted to single underlining in the resulting form template.
Hyperlinks that reference unsupported protocols: All hyperlinks are converted, but if the hyperlink uses a protocol other than http:, https:, file:, ftp:, or mailto:, the hyperlink will not work when a user clicks the link.
Character styles and text effects: Superscript, subscript, and strikethrough formatting styles are preserved during the conversion process. Other text effects and styles are not supported in InfoPath and are discarded during the conversion process. Embossed or engraved text is imported as gray text, and the embossed or engraved style is discarded.
Header and footer formatting: Header and footer text in the Word document will be converted to header and footer text in the resulting InfoPath form template. The font setting applied to the first header or footer section in the document is applied to the entire header or footer in the form template.
Section settings: In Word, sections are used to vary the layout for a document within a page or between pages. InfoPath does not support sections, so they are discarded during the conversion process. Any settings that are applied to the first section in the document are applied to the resulting InfoPath form template.
Font conversion: Although InfoPath imports the fonts from a document when creating a new form template, if the fonts in the document are not available on the computer where you perform the import, alternate fonts will automatically be selected for the form template.
Negative page margins: Negative left, right, top and bottom margins will be imported as 0.
Negative margins and padding settings: Negative margin or padding settings for any object will be imported as 0.
Design Checker Note
After importing a Microsoft Excel or Word file, if there are errors or warnings they will be displayed in the Design Checker task pane (for additional information on the Design Checker see the Design Checker section.) However, unlike errors and warnings regarding browser-compatibility issues, import errors and messages are stored in an XML Resource file named: ImportErrors.xml. As such, after correcting these issues they are not automatically removed from the Design Checker task pane by clicking the Refresh button. Once all issues have been resolved, select Resource Files from the Tools much and remove ImportErrors.xml.
Controls and Data Binding
Figure 58 Controls Task PaneInfoPath uses simple controls to display and edit data in a form, including controls for fields, groups of fields, and repeating groups of fields. These controls are bound to the underlying XML data of the form. They can be programmed with sophisticated data validation to ensure that the form is correct. To help users recognize required fields in a form, most controls have a Cannot be blank property to visually identify required fields.
Binding Controls using the Controls task pane
If you create a new form by dragging controls from the Controls task pane onto the form area, by default InfoPath will automatically add a new field to the data source shown in the Data Source task pane and bind the control to that field. If you prefer, you can clear the Automatically create data source check box in the Controls task pane; when you drag controls onto the form, InfoPath prompts you to select the field in the data source to which you want to bind the control.
Figure 59: Automatically create data sourceBinding Controls using the Fields task pane
You can also bind controls to fields or groups in the data source from the Fields task pane. To do this, drag the field you want to bind from the Fields task pane onto the form. InfoPath automatically selects a control type to match the field in your schema. The control type InfoPath recommends is based on the data type and the number of allowed occurrences for an element. For example, dragging a group onto a view will result in a section control being recommended, and dragging a repeating element will result in a list being recommended. Repeating tables or sections are recommended for repeating groups.
If the control InfoPath chooses isn't to your liking, you can choose from other compatible controls. To do so, right-click the field in the Fields task pane to see the list of potential controls.
Figure 60: Change control type To change a control already on a view, right-click the control on the form and point to Change To on the shortcut menu. InfoPath presents a list of the compatible control types for the field.
Figure 61: Use the Change To command to change the control bound to a fieldChanging the Data Binding of a Control
In the course of form design, it might become necessary to change the data source element that a control is bound to. To set or change the field that a control is bound to, right-click the control and click Change Binding on the shortcut menu (or click Change Binding on the Edit menu). Select the new element or attribute that you want to bind the control to, and then click OK.
Figure 62: Use the Change Binding command to bind a control to a different field
Note that there are limitations to the data fields that a control can be bound to. For example, a control cannot be bound to a repeating field in the data source unless it is located within a repeating section, table, or list for that field.
When designing a form for data entry you can use the Move to next control automatically when limit is reached property of the text box control to aid the user in the data entry process. This property is used in conjunction with Limit text box to property so that when the character limit has been reached for the text box, focus will automatically move to the next control. This is especially useful for items such as phone numbers, zip codes, etc.
To access these properties, right-click on a text box control, choose Properties and select the Display tab.
Figure 63: Move to next control
If you are writing code that requires a ViewContext or XmlToEdit identifier, these attributes are available on the Advanced tab of the Properties window for each control. These values are typically needed when using the ExecuteAction method on the underlying XML document.
Figure 64 Advanced Properties
Secondary Data Sources
In addition to the primary data source for a form, InfoPath provides the ability to connect to secondary data sources. Like the main data source, secondary data sources can draw from an XML document, a database, or a SOAP Web service. Additionally, a secondary data source can draw from a Windows SharePoint Services List, a connection from a Microsoft Office SharePoint Server Data Connection Library, or a REST web service (InfoPath 2010 and 2013).
Setting Up a Secondary Data Source
To add a secondary data source, click on the Data ribbon and select the appropriate data source. To view existing data connection or to add a new data connection, you can also click Data Connections on the Data ribbon, and then click Add in the Data Connections dialog box.
Figure 65 Data Connection Dialog
Storing a copy of the data for offline use
Just like the main data source for the form, the Data Connection Wizard is used to set up secondary data sources. When setting up secondary data sources you will have an option to Store a copy of the data in the form template. Enabling this option will cause InfoPath to query the data source and create a copy of the data to be stored locally for use in Offline mode. (This option is only available for rich-client scenarios.) The data is stored in an XML file in the XSN with a name of: connection_offline.xml (where “connection” is the name of the data connection.) Each data connection that has been enabled to store a copy of the data will have a corresponding “_offline” XML file.
By creating a copy of the data for offline use it will enable users to fill out forms based on this form template while their computers are not connected to a network or cannot access a specific data source.
SECURITY NOTE: Before configuring the form template to allow forms to cache the data from a secondary data connection, consider what could happen to the data if the computer is lost or stolen. If you are using a secondary data connection to get sensitive data, you may not want to enable this feature to protect the data in case the computer is lost or stolen. If the form is retrieving sensitive data, you may want to configure the secondary data connection to get data only if the computer is connected to a network.
Figure 66: Store data for offline use
Globally enabling or disabling the ability to cache queries for offline use is set on the Offline category of the Form Options screen, which can be accessed from the backstage screen.
Figure 67 Offline Category of the Form Options screenWhen querying data in offline mode, records will be returned from the “offline” XML file. As such, when designing the logic in your form, there are a few options for what to display to the user – these options would be custom coded by the developer:
When in offline mode, don’t display any results to the user
Display all the results
Filter the data returned, populate a “dummy” Resource XML file and use this file to display the results to the user
After the secondary data source is set up, InfoPath prompts you to enter a name to identify the data source. You can also choose whether to connect to this secondary data source when the form is opened. If you choose to connect to the data source when the form is opened, the data in the secondary data source is available immediately when the form is opened. If you clear this option in the Data Connection Wizard, you must use code (or a Rule using a “Query using a data connection” action) to connect to the data source:
Figure 68: Provide a name for the data connection
Once you have added the secondary data source it will appear in a drop-down list in the Fields task pane. The form designer can bind the elements and attributes of a secondary data source to controls in the view. Note that the data displayed in the controls will not be saved or submitted with the data in the main data source.
Figure 69: Secondary data connection
SharePoint List Data Connection
The SharePoint list data connection allows you to use the rows in a Windows SharePoint Services library or list as a data source in your InfoPath form. Like other data connections, you use the Data Connection Wizard to create a data connection to a SharePoint list. Specify the URL to the SharePoint site where the library or list is located and then click Next. The wizard will provide a list of all the available lists and libraries on that site for you to choose from. Finally, select the fields from the list you want to use in the data connection, name the connection, and Click Finish to create the data connection
Hint: You can specify either the URL to the site or to a view. If you enter a URL to a view, the default settings for that view will be pre-selected throughout the wizard.
REST Web Service Data Connection (InfoPath 2010 and 2013)
A REST (Representational State Transfer) web service accesses data differently from SOAP web services. In a REST web service, data is treated as a resource, much like a static XML or HTML file would be, and the request URI encodes the resource to retrieve. For example, to retrieve the orders for a particular employee, a REST web service might expose a URI like:
Binding Controls to a Secondary Data Source
Just as you can bind controls to fields in the form’s main data source, you can also bind controls to fields in a secondary data source. It is important to remember that while these controls work the same as controls bound to the main data source, the data they display will not be saved or submitted with the data in the main data source. Controls bound to secondary data connections are useful for providing additional data to the user to aid in filling out a form.
To bind a control to a field in a secondary data connection, choose the data connection from the Fields dropdown listbox on the Fields task pane. Drag the field you want to bind from the Fields task pane onto the form. InfoPath automatically selects a control type to match the fields in your schema. The control type InfoPath recommends is based on the data type and the number of allowed occurrences for an element. For example, dragging a group onto a view will result in a section control being recommended, and dragging a repeating element will result in a list being recommended. Repeating tables or sections are recommended for repeating groups.
Figure 70: Add controls for secondary data connection fieldsUsing a Secondary Data Source in controls
A secondary data source can be used to provide the choices for a list box control, drop-down list box control, combo-box control or multi-select list box control using the Properties dialog of the control. To draw a list of choices from a secondary data source, select Look up values from an external data source on the Data tab in the list box’s Properties dialog box.
Figure 71: Using a secondary data connection in a controlIn the Data Source box, select the secondary data source you want to use or click Add to establish a new Data Connection using the Data Connection Wizard. Set the Entries box to a repeating entry in the data source. Finally, select fields from the repeating entry to use for the Value and Display name boxes. The Value property will be saved with the form, and the Display name property will be shown in the list box. These two properties can be the same or different.
Using a Secondary Data Source from code
Another scenario in which secondary data sources are useful is in code. When a secondary data source is created, it is added to the DataSources collection of the XMLForm (DataObjects collection of the XDocument object in script) in the InfoPath object model. This is useful for easily accessing the data of the secondary data source as XML.
//Get a reference to the data source
DataSource ds = this.DataSources["GetCustomers"];
//Query the connection
//Create a navigastor object to walk the DOM
XathNavigator xn = ds.CreateNavigator();
Filters provide an easy way to work with a subset of entries in a repeating section or a repeating table. A filtered repeating section or table displays only the rows that meet conditions specified in the properties of these controls. The conditions can be either static (e.g. always display employee records for employees working in a particular office), or dynamic (e.g. the user in the editor will be able to choose from a dropdown the location of the employees for which records he or she wants to see).
Filtering Repeating Tables and Sections
You can use filters to control the data displayed in a repeating table or repeating section control, based on other values in the form. To do so, right-click on the control you want to filter, and click Properties. On the Display tab of the Properties dialog, click the Filter Data… button.
To add a new filter for the table or section, click the Add… button, and then specify the conditions you want to use to filter the data. Only data that meets the criteria you specify will be displayed. You can choose criteria based on static values, the values of other fields in the form’s main data source or in secondary data connections, or on formula calculations you specify.
NOTE: Filters are not available on controls that are bound to a secondary data source nor are they available on browser enabled forms.
Figure 72 Specify Filter Conditions dialog
Note that filters only affect how data is displayed. It does not change the underlying data in the form. This means that you can have multiple repeating tables or repeating sections bound to the same data, and use filters to display different portions of the data in each control. Also notice that you can specify multiple filters for a single control. Filters are evaluated in a top-down order so the order of filters can be important. The full set of data will be filtered by the first filter. The resulting filtered data will be filtered by the second filter, and so on. You can use the Move Up and Move Down buttons on the Filter Data dialog to change the order of filters for a control.
Filtering ListBox Choices
Filters can also be used to filter the list of options displayed in a Drop-Down List Box, List Box, Combo-box or Multi-Select List Box control. When you create a list box control that draws its entries from a repeating list or group in the form’s main data source or in a secondary data connection, and click the Select XPath button, the Select a Field or Group dialog is displayed. Clicking the Filter Data… button displays the same Filter Data dialog (seen in Figure 55) used to specify filter conditions for repeating tables and repeating sections. Use the same steps to create filters for the list box choices.
Figure 73 Filter Data in the Select a Field or Group dialog
Once you have completed the filter and set the Value and Display fields, if the data connection supplying the values contains duplicate entries, you can choose to display just unique values by enabling the option: Show only entries with unique Display names.
Figure 74 Show unique entries
To make forms more responsive to users and to help call attention to special properties or conditions in the form, InfoPath provides the ability to apply conditional formatting to controls and sections of a form. Conditional formatting allows the form designer to specify the formatting of plain text components and table rows based on Boolean conditions. InfoPath stores the conditional formatting in the view’s XSL transform files where they are applied whenever the condition is met in the document. Conditional formatting allows broad support across controls as well as the additional ability to set read-only or disabled state on controls.
Conditional Formatting in InfoPath 2007
To access the Conditional Formatting dialog box, select the control you want to apply conditional formatting to, and then click Conditional Formatting on the Format menu. You can also right-click the control you want to apply conditional formatting to and choose Conditional Formatting.
Figure 75 Conditional Formatting
To add a new conditional format, click Add in the Conditional Formatting dialog box to open the Conditional Format dialog box. Use the boxes at the top of the dialog box to define the condition or conditions to that will cause this formatting to be applied. The condition can test the value of the current field, another field or group, an XPath expression or the user’s role. Next, define the formatting you want to apply for that condition. You can change the font color and background color of the control, make it bold or italic, or depending on the control hide the control on the form altogether. For example, if you were building an expense report form, you might want to build a condition such as “if expense is greater than 75” that causes the font color to change to red, to remind the user that expenses greater than $75 require a receipt.
Figure 76 Conditional Formatting Dialog Box
If at a later time you want to modify the conditional formatting of a control, you can select the condition you wish to modify in the Conditional Formatting dialog box, and then click Modify. This opens the same Conditional Format dialog box you used to create the conditional formatting and allows you to make any modifications to the conditions or associated formatting that you want.
There may be instances in which you need to create conditional formats that overlap or conflict. For these scenarios, InfoPath provides the Move Up and Move Down buttons in the Conditional Formatting dialog box. In the event that conditional formats overlap or conflict, the format that is higher in the list takes precedence and the other conditional formats are ignored. If you find that your formats are not being applied as you would like, try changing the order of the formats in the list.
Conditional Formatting in InfoPath 2010 and 2013
To streamline user interaction, conditional formatting is now accessed through the Rules task pane. To access the Rules task pane, select the control you want to apply conditional formatting to, and then click Manage Rules on the Properties ribbon.
To add a new conditional format, click New in the Rules task pane. Use the Condition link to specify the conditions under which formatting will be applied. The condition can test the value of the current field, another field or group, an XPath expression or the user’s role. Next, define the formatting you want to apply for that condition. You can change the font color and background color of the control, make it bold or italic, or depending on the control hide the control on the form altogether. For example, if you were building an expense report form, you might want to build a condition such as “if expense is greater than 75” that causes the font color to change to red, to remind the user that expenses greater than $75 require a receipt.
Figure 77 Conditional Format dialog box
There may be instances in which you need to create formatting rules that overlap or conflict. For these scenarios, InfoPath provides the Move Up and Move Down buttons in the Rules task pane. In the event that conditional formats overlap or conflict, the format that is higher in the list takes precedence and the other conditional formats are ignored. If you find that your formats are not being applied as you would like, try changing the order of the formats in the list. To move a formatting rule, right-click on it in the Rules task pane and choose Move Up or Move Down.
To help ensure that a form contains valid data, InfoPath provides three layers of validation for a form: XML Schema validation, custom data validation, and code-based data validation. These data validation layers are constantly and automatically executed on the underlying XML data of a form while the user is filling it out. Any values entered are validated based on both their data type and the business logic constraints on the form. Forms that contain validation errors can be saved but cannot be submitted to a back-end system.
InfoPath is constantly validating the form while it is being filled out. Even if there are no custom or code-based validation rules associated with the form, InfoPath will ensure that the structure of the data is correct according to the schema and that any values entered are of the appropriate data type.
Validation errors are associated with fields or groups (i.e., XML nodes), and not the controls in a view. Because a view is not required to have a control bound to each and every field or group in the data source, you may not see all validation errors on the current view when filling out a form. Additionally, since errors are associated with fields or groups, if the same field is bound to multiple controls in the form, you will see an error on each instance. Also, any rules associated with repeating groups will be applied to every item in the collection that repeats.
Data Validation User Interface
InfoPath provides two basic ways to warn the user that a field or group in the form they’re filling out is invalid.
When a user enters an invalid value into a control with an inline alert, InfoPath marks the control with a dashed, red border. If the field is blank and the Cannot be blank property has been set, the control will display a red asterisk instead.
Figure 78 Examples of inline alerts
Inline alerts also have two text messages associated with them. The ScreenTip error text contains a brief error message indicating the problem with the data. The Dialog box message error text contains a more detailed explanation of the problem or a description of valid values for the field. An inline alert displays the ScreenTip error message when the insertion point rests on a field with an error. In the rich client environment, the user can open a dialog box containing the full Dialog box message text by right-clicking the field and clicking Full Error Description on the shortcut menu, or by clicking Show Error Message on the Tools menu. In a browser-enabled form, the user can hover over the invalid field to see the Screen Tip error message and if there is a more detailed message, the Screen Tip is actually a hyperlink that the user can click to get additional details on the error. When users fill out a form in the rich client environment, InfoPath allows them to navigate through all inline errors in the view by clicking Go to Next Error on the Tools menu. After an invalid value is corrected, InfoPath removes the red border or underline from the control.
Dialog Box Alerts (Rich client forms only)
When a user enters an invalid value into a control with a dialog box alert, InfoPath displays an error message containing the Dialog box message error text immediately when an invalid value is entered. When the user clicks the OK button in this dialog box, InfoPath applies the same dashed red border or red underline to the invalid field.
Figure 79 Example of a dialog box alert
Active Dialog Box Alerts (client only)
Code data validation provides the ability to display one other kind of alert, an Active Dialog Box Alert. These can be used on the Changing Event (OnBeforeChange in 2003) so that if a user enters an invalid value into a control with an active dialog box alert, an error message dialog box displays, just as with a normal dialog box alert. However, after the user clicks the OK button in this dialog box, the invalid value is rolled back to the previous (valid) value. Thus, there is usually no way to enter an invalid value in a field protected by active dialog box alerts. There are some cases, however, in which an active dialog box alert is immediately followed by an inline alert, which results in an invalid intermediate value being entered into a field.
public void field2_Changing(object sender, XmlChangingEventArgs e)
if (e.NewValue != "Hello")
e.CancelableArgs.Cancel = true;
e.CancelableArgs.Message = "Invalid Value";
e.CancelableArgs.MessageDetails = "This field can only contain 'Hello'!";
XML Schema Validation
InfoPath tries to guarantee that any forms that are generated from a form template are valid against the schema of the form template. InfoPath validates the data types of all data entered into a form. It also enforces any restrictions the schema may place on the data. For example, if the following element is found in the schema, InfoPath will require that values entered into the field be exactly three characters long; longer or shorter values are flagged as invalid data with an inline alert:
Schema validation applies to data entered through the user interface, but it also applies to changes made through code. If a code function sets a value into a field that is invalid according to the schema, an inline alert results, just as if the user had entered the value manually. There is one exception to this behavior: if a code function attempts to make an invalid change to the underlying structure of the form, such as adding a child element to an element that doesn’t allow children, InfoPath rejects the change with an active dialog box alert.
Note that it may be difficult or impossible to specify all the types of validation you might want to apply to a form. For example, schema validation cannot check values against a Web service method, and it may be difficult to describe complex logical constraints between fields. For this reason, InfoPath provides two other types of data validation—custom Data Validation and Event Handlers data validation.
Custom Data Validation
InfoPath provides the ability to create the most common types of custom data validation through Validation rules.
Adding Data Validation in InfoPath 2007
InfoPath provides the ability to create the most common types of custom data validation through a Data Validation Rule dialog box. To add a data validation rule to a field or group, right-click the field or group you want to add a rule to in the data source pane, and then click Properties on the shortcut menu. Click the Validation tab in the Properties dialog box. You can also start by right-clicking a control on the form that is bound to the relevant field or group and selecting Data Validation from the Context menu. Regardless of the method you choose, the validation rule will be associated with the data field or group.
Click Add in the Data Validation dialog box to open a new Data Validation dialog box.
Figure 80 Add data validation to a field
Click the Add… button to add a new data validation condition to a field.
Figure 81 Data Validation dialog box
Adding Data Validation in InfoPath 2010 and 2013
To add a data validation rule to a field or group, select the control you want to apply conditional formatting to, and then click Manage Rules on the Properties ribbon. Click the New button and choose Validation as the tile of rule to create.
Figure 82 Data Validation rule
Constructing Validation Rules
Validation rules can be made up of a number of separate expressions joined by logical AND or OR operators. A validation expression has three fields that combine to form a logical test:
An operand This can be the current field or group, another field or group, the user’s role or an XPath expression. Note that regardless of the operand selected, the validation rule applies only to the field that was originally selected. In other words, it’s possible to create expressions that will cause a field to be marked as invalid even though the data validation expressions don’t apply to that field at all.
An operation InfoPath provides a significant list of available operators such as ‘is equal to’ and ‘is less than’.
A value This can be either a hard-coded value in the expression or the value of another field or group in the form.
The ScreenTip box is used to provide a short error description, and the Message box is used to provide a more detailed explanation of why a field failed validation. Note that in data validation rules you can only create inline alerts or dialog box alerts. It is not possible to create active dialog box alerts in rules.
Data Validation using Patterns
Patterns can be used anywhere the condition builder appears, but they are most commonly used with Data Validation. To use a pattern for data validation, set the operation field in the condition builder to matches pattern or does not match pattern. Then choose Select a pattern… from the value field in the condition builder to display the Data Entry Pattern dialog.
Figure 83 Using Data Validation to control the Data Entry Pattern
You can pick a standard pattern from the Data Validation dialog’s right-hand drop-down list box, or you can customize a pattern by editing it in the “Custom Pattern” text box. You can also use the “Insert Special Character” drop-down to insert commonly used special characters. InfoPath patterns follow the W3C standard for XML Schema Regular Expressions. The following references provide more in-depth information on these standards:
Formal XML Schema regular expression definition:
W3C examples as used in schemas (the values can be copied as-is into the text box above):
Code based Data Validation
Although the design mode UI covers the most common validation rules, you may need to provide a more complicated rule for your specific form. For example, you might want to validate a specific field based on the value in a database. In such a case, you can extend the basic functionality provided in the data validation rules by writing script or managed code.
Creating Code-based Data Validation in InfoPath 2007
To create a code validation rule in InfoPath 2007, right-click on the field or group, select Programming and then choose the specific event (Changing, Validating or Changed) that you want to perform the validation. Selecting the event will launch the code editor and automatically create a function for the event you selected. The function you choose depends on what kind of validation errors you want to present to the user and what other work you need to do.
Figure 84 Use the Data Validation dialog box to add code data validation
Just as with custom data validation, code validation functions are associated with a particular field or group. This association does not necessarily mean that the function is validating that field or group. Instead, it simply means that the function runs whenever the value of that field or group (or any of its descendants) has been modified.
Creating Code-based Data Validation in InfoPath 2010 and 2013
To create a code validation rule in InfoPath 2010 and 2013, switch to the Developer ribbon, select the field or control you wish to validate, and then choose the specific event (Changing, Validating or Changed) that you want to perform the validation. Selecting the event will launch the code editor and automatically create a function for the event you selected. The function you choose depends on what kind of validation errors you want to present to the user and what other work you need to do.
Figure 85 The Developer ribbon
InfoPath 2010 Data Validation Events
The Changing Event (client only)
The Changing (OnBeforeChange in 2003) event is used to validate a change in the data of a field or group. While this event handler is working, the form’s underlying XML document is placed in a read-only state. The Changing event gives you the opportunity to reject the change that has been made to a field or group and roll the data back to a previous valid value before it is written to the XML document.
If you determine that the value of a field is invalid, set the CancelableArgs.Cancel (ReturnStatus for 2003) property of the XmlChangingEventArgs (DataDOMEvent for 2003) object to true. InfoPath will reject the new value of the field and display a dialog box to the user explaining why the data is invalid. You can specify the message displayed in the dialog box through the Message and MessageDetails (ReturnMessage for 2003) property of the XmlChangingEventArgs object:
Public Sub field1_Changing(ByVal sender As Object, ByVal e As XmlChangingEventArgs)
If e.Site.InnerXml = "" Then
If e.NewValue <> "Hello" Then
e.CancelableArgs.Message = "Input Error"
e.CancelableArgs.MessageDetails = "This field can only contain 'Hello'!"
e.CancelableArgs.Cancel = True
Setting the CancelableArgs.Cancel property to True (or ReturnStatus property to false) results in an active dialog box alert. The Message (or ReturnMessage) text is displayed in a dialog box when the Changing (OnBeforeChange) event returns. When the user clicks OK, the invalid value is rolled back to a previous value.
The Validating Event
Like the Changing event, the Validating (OnValidate in 2003) event is generally used to validate a change to a field or group. However, the Validating event cannot be used reject a change to a field or group. It’s important to note that during the Validating event, the form’s underlying XML document is read-only, so you can’t make changes to it.
public void field2_Validating(object sender, XmlValidatingEventArgs e)
//Only perform the test on the ValueChange action
if (e.Operation.ToString() == "ValueChange")
//Make sure something has been entered
if (e.Site.InnerXml != "")
//If previous Validation errors have been added, clear those
if (this.Errors.Count > 0)
//Check the value of the field
if (e.Site.InnerXml != "Hello")
this.Errors.Add(e.Site, "ValidationError", "The data is invalid", "The only valid string is 'Hello'");
//We could also use the following to report the error
//e.ReportError(e.Site, true, "The data is invalid", "The only valid string is 'Hello'", 0);
Adding errors to the Errors collection by calling Errors.Add or ReportError results in an inline alert. The ScreenTip text will display when a user rests the insertion point on an invalidated field, and the Message text will display in the error dialog box.
The Changed Event
Typically, the Changed (OnAfterChange in 2003) event is used to perform calculations and make changes to the XML document of the underlying form based on the changes that have occurred in a field. This event allows changes to a field to have side effects in the form. For example, you might use this event to query a Web service based on the new value of a field:
Public Sub field3_Changed(ByVal sender As Object, ByVal e As XmlEventArgs)
If e.UndoRedo Then
' An undo or redo operation has occurred
'Get a reference to the SDS bound to the Web service
Dim theDataObject As DataSource = Me.DataSources("GetSelectedCustomer")
'Create a Navigator object so we can walk the DOM
Dim dsXN As XPathNavigator = theDataObject.CreateNavigator()
'Get a reference to the queryField where we will set the parameter
Dim queryValue As XPathNavigator = dsXN.SelectSingleNode( _ "/dfs:myFields/dfs:queryFields/tns:GetSelectedCustomer/tns:CustID", Me.NamespaceManager)
'Set the queryField value to the value of what we just entered
queryValue.InnerXml = e.Site.InnerXml
'Query the SDS
When designing a form, you can use rules to automatically display a dialog box, set a field's value, query or submit to a data connection or switch views in response to certain events and conditions. The events can include a change to a particular field or group in the data source, the click of a button, the insertion of a repeating section or row in a repeating table or the opening or submission of a form.
You can specify conditions on rules so that they only execute their actions under certain conditions. The conditions can include whether the value of a field is blank, is within a specified range, equals the value of another field, or starts with or contains certain characters. You can also add multiple actions for each rule. For example, you can automatically open a new form and display a dialog box message when a field's value exceeds 100.
There are four basic areas where you can rules to customize the behavior of the form. Each area is discussed briefly here.
When a Field or Group changes
When a field in a form changes, any rules attached to that field will run.
To add a rule in InfoPath 2007 that runs when a field or group changes, right-click on the field in the Data Source task pane, and choose Properties. On the Rules and Merge tab, click Add to add a new rule. You can also right-click on a control bound to the field and click Rules, or right-click on the control bound to the field and click Properties, and then click the Rules… button on the Data tab.
To add a rule in InfoPath 2010 and 2013 that runs when a field or group changes, display the Rules task pane by clicking Manage Rules on the Home ribbon. Select the field you wish to add a rule to and click New to add it.
When the Form is opened
You can run rules when the form is opened. This can be useful for pre-filling fields in the form with data. In InfoPath 2007, to add a rule that runs when the form is opened, click Form Options on the Tools menu. On the Open and Save tab, click the Rules button. In InfoPath 2010 and 2013, to add a rule that runs when the form is opened, click Form Load on the Data ribbon.
When a button is clicked
Instead of writing code, you can use a rule to perform actions when a button on the form is clicked.
To add a rule in InfoPath 2007 that runs when a button is clicked, right-click on the button and choose Properties. Click the Rules… button to add a new rule to the button.
To add a rule in InfoPath 2010 and 2013 that runs when a button is clicked, select the button and then choose Manage Rules from the Properties ribbon.
When the form is submitted
You can also use rules to perform custom submit actions. This can be useful if you need to submit to multiple locations with a single action.
To add a rule in InfoPath 2007 that runs when the form is submitted, click Submit Options from the Tools menu. Check the Allow users to submit this form option if it is not already checked, and then select Perform custom action using Rules. Click the Rules… button to add a new submit rule to the form.
In InfoPath 2010 and 2013, to enable the form's default submit command to run a rule, select Form Submit from the Data ribbon.
Actions in rules
There are several actions that you can perform in a rule. You can combine these actions to perform complex tasks that would otherwise require code. It’s important to note that not all actions are available in all scenarios. The Action dropdown in the Action dialog box will display only those actions which are allowed in a given context.
Show a message: This opens a simple message dialog with an OK button. You can use this action to report a static message to the user.
Show the value of a field or formula: This opens the same dialog as the Show a dialog message, but uses the result of a formula as the message. This can be used to create dynamic messages for the user based on data in the form.
Switch views: This will switch the form to another view. You can use this action to set the initial view of the form when the user opens it, or to produce a “wizard” style form with Next and Back buttons.
Set a field’s value: This will set a field’s value. You can set the field to a static value, the value of another field in the form’s data sources, or the result of a formula.
Query for data: This will query the specified data connection. Used in conjunction with the Set a field’s value action, this action can be used to automatically query a data connection with parameters.
Submit data: This will submit all or part of the form using a specified data connection. This can be useful in building a rule that submits to multiple data connections at one time.
Open a new form to fill out: This will open a new blank form using the form template specified. This can be useful when additional information is required from the user in additional forms. (For example, an itemized expense report for high value expenses).
Close the form: This will close the current form, from where the Rule is executed, only. So if other forms are opened, they will be unaffected by this Rule.
Sign signature line: This will find the first signature line control with the conditions specified, and apply the signature picture specified in the rule.
When the Don’t run remaining rules if the condition of this rule is met checkbox at the bottom of the Rule task pane is checked, any rules in the Rules task pane that come after this one will not run. Note that this only occurs if the rules conditions are met. If not, then the rule is ignored and subsequent rules are processed normally. This can save time writing rules and updating conditions.
For example, instead of creating the following rules:
if the user's role is executive, switch the view to "Submitted" view
if the total is greater than $1000 and the role is NOT executive, switch to "Receipts" view
if the order includes labor and is NOT greater than $1000 and the role is NOT executive, switch to the "Employer" view
if NOT all of the above conditions, switch to the "Approval" view
you can create the following:
if the user's role is executive, switch to "Submitted" view and STOP
if the total is greater than $1000, switch to "Receipts" view and STOP
if the order includes labor, switch to the "Employer" view and STOP
Switch to the "Approval" view
Notice how much simpler and easier to maintain these rules are.
The Rule Inspector (called the Logic Inspector in InfoPath 2007) is a tool to allow users to see all or some of their form logic at a glance. If a user is curious about the way a form is behaving, yet doesn’t know where to start looking, the Rule Inspector can show the pertinent logic for the whole form or a particular node. In addition, the logic will be displayed in a flattened view so that the user can avoid having to click through a number of dialogs to reach the information.
Launching the Logic Inspector in InfoPath 2007
There are three entry points for displaying the Logic Inspector:
From the Tools menu, select Logic Inspector
On the context menu of a node in the Data Source Task Pane (right-click on a node and select Logic Inspector)
On the context menu of a control (right-click on a control and select Logic Inspector)
Launching the Rule Inspector in InfoPath 2010 and 2013
There are two entry points for displaying the Rule Inspector:
From the Data ribbon, click Rule Inspector
On the context menu of a node in the Fields task pane (right-click on a node and select Rule Inspector)
Rule Inspector Views
There are two main views for the Rule Inspector: form view and the node view. The form view is reached via the Rule Inspector button on the Data ribbon.
Figure 86 InfoPath 2010 Rule Inspector Dialog
The node view is reached through using the context menu of a node or control, by clicking the Rule Inspector menu item.
Figure 87 Rule Inspector node view
NOTE: The Node View of the Rule Inspector can also be displayed by clicking on a node hyperlink in the Form View.
The node view is always accompanied by the form view – it is never displayed alone, while the form view can be viewed alone or alongside the node view.
When in Form View, the Rule Inspector will display any nodes that contain Data Validation, Calculated Default Values, Rules or Programming. The Node View expands the information to include logic that depends on the selected field or group, logic that gets triggered by a change in the selected field or group and logic that may change the selected field or group.
Each view in the Rule Inspector has a Print option that prints just that specific view so the user can print out only that information which is needed.
Roles allow you customize the behavior of an InfoPath form based on the identity of the user. Using roles as conditions, you can set up conditional formatting and data validation to facilitate workflow in your form. You can assign roles based on individual user identities, or based on Domain groups in Active Directory. When a user opens a form, InfoPath determines whether that user is assigned to an existing user role. For example, if the user role assignments are determined by network name, InfoPath checks the user's name against the user's network credentials before opening the form. In the form, the name of the current user role appears on the status bar.
Note: You should not use roles to restrict access to sensitive data in a form. Even if you make a form read-only or hide certain controls based on roles, users can potentially use a text editing program such as Microsoft Notepad to view or modify the form (.xml) file.
Defining User Roles
To define a User Role in InfoPath 2007, you use the User Roles… button on the Tools menu. To define a User Role in InfoPath 2010 and 2013, you use the User Roles… command on the Data ribbon. Both commands display the Manage User Roles dialog. To add a new user role, click the Add button and type in the name of the role to add.
Figure 88 Add User Role dialog
When you create a new user role, you can assign users to it in the following ways:
By specifying domain\user names (for example, "sales\andrew").
By specifying groups. For example, you can specify an e-mail distribution list that contains the names of all members of the marketing team.
By specifying user names that come directly from the form. For example, if your form contains a Manager text box, you can specify the field to which that text box is bound.
You can create as many user roles as you like, but you should be careful that they do not overlap. If a user belongs to multiple roles, InfoPath will always assign the user to the first role for which they qualify. Users who are not assigned to an existing user role are automatically assigned to the user role that is specified as the default role. The default role is also used for users who are part of a group but who are working offline. One user role is always set as the default.
If you want to apply a particular user role to users who open your form for the first time, you can specify an initiator role. For example, you can define an initiator role named "Project Owner" that applies to users who fill out new project specification forms. A user who is assigned to a different user role is automatically reassigned to the project owner role when he or she opens a new project specification form. However, the next time that user opens the same form, InfoPath uses the person's assigned user role instead of the initiator role.
Working with user roles
Once you have created roles for your form, you can start using the roles in the condition builder in Conditional Formatting and Data Validation rules.
Figure 89 Condition Builder for managing role
Testing User Roles
If a form has multiple user roles, you can preview the form as different roles to test the appearance and behavior of each distinct role. For example, if you created a special summary view of your form for managers, along with a rule that switches the view based on user role, you can test that view with the manager role. In the preview window, the name of the current user role appears on the status bar.
In InfoPath 2007, to preview the form as a specific role, click Form Options on the Tools menu. In the Preview tab, select the User role you wish to preview the form as.
In InfoPath 2010 and 2013, click Advanced Form Options on the File menu. In the Preview tab, select the User role you wish to preview the form as.
Publishing and Security
When designing an InfoPath form, it is important to keep the two concepts of deployment and security in mind. This section discusses the topics a form developer should consider when building a template.
Because of the ever present threat of malicious users attempting to write harmful code, InfoPath was designed with security in mind. All form templates can run in one of three possible security zones, depending on where a form is located: Restricted, Domain and Full Trust. These security zones control the features a form template has access to, the external data sources it can access, and the object model methods and properties it can use in managed code. This design helps form template designers as well as form users to mitigate the risk of maliciously designed form templates.
The Restricted security zone restricts all communication outside of the form template and is the default security level. This security zone is intended to prevent harmful forms from transmitting any data from your computer to a malicious attacker. When running in this security zone, most of InfoPath’s more advanced features are disabled, including Custom Task Panes, Data Connections (except email submit), ActiveX Controls, Managed Code, and Roles. In addition, a form template running in the Restricted zone can only call object model methods and properties at security level 1, as documented in the InfoPath Developer’s Reference.
The Domain security zone contains a form to a particular Internet Security zone as defined in Internet Explorer security settings on the machine. The form is allowed to communicate with other data inside of this domain but is restricted from retrieving data from other domains unless it is located on a trusted site or in the local machine IE security zone. Domain forms can call object model methods and properties at security level 1 and 2.
NOTE: When a browser-compatible form template is published, the security level will automatically be elevated to Domain.
The Full Trust security zone will allow you to run a form with full trust on the local machine. This security zone can only be used when using a form template signed with a digital signature that matches a trusted publisher on your machine, or by installing the form template and setting the requireFullTrust XSF attribute to yes. By using this setting, you can access object model calls to the local machine such as “File|Save” as well as disable certain security prompts that appear when running in a more restrictive security zone.
Specifying a Security Zone
The InfoPath designer will automatically select the appropriate security level (either Restricted or Domain) based on the features you are using in the form. If necessary, you can manually override this setting and select a security level for the form template. In InfoPath 2007, select Form Options from the Tools menu to display the Form Options dialog box. In InfoPath 2010 and 2013, select Advanced Form Options from the File menu. In the Form Options dialog select the Security and Trust category. Uncheck the Automatically determine security level check box, and then select the desired security level.
Figure 90 Form Security using Self-Signed certificate
Publishing a form template
Once you have finished designing an InfoPath form template, you must publish it so that it is available for users to fill out. Remember that when users fill out the form template and save, the XML form data generated will contain a reference to the published location of the form template. For this reason, you should publish your form template to a shared location, like a shared folder, a SharePoint form library, or a Web server. To help you in this process, InfoPath provides the Publishing Wizard.
The InfoPath Publishing Wizard guides form designers through the process of making forms available to other users, and allows them to quickly notify users when a form becomes available. It provides the ability to publish a form template to several different locations. When launching the Publishing Wizard, if the form template has not yet been saved InfoPath will prompt the user that the form must first be saved before it can be published.
Figure 91 Publishing Wizard Save Warning
In addition, it will perform a compatibility check before the Publish Options page appears. This will allow users to correct potential errors in the form before publishing those errors.
Figure 92 Publishing Wizard Errors Message
NOTE: The above dialog will only be displayed for errors – not warnings.
The Publishing Wizard can be launched by selecting Publish from the File menu or Publish Form Template from the Design Tasks Task Pane. Once the form has been saved and any errors resolved, the first screen of the Publishing Wizard is to select where to publish the form template.
Figure 93 Publish Options
Publishing to SharePoint
Selecting the SharePoint option and clicking Next enables the developer to enter a URL to the Office SharePoint Server where the form template is to be published.
Figure 94 Publishing to SharePoint - Enter URL
After clicking Next, the options available are dependent upon whether InfoPath Forms Services is installed on the SharePoint server, as well as if the form template has been designed for client only or for client and browser use.
Figure 95 Publishing to SharePoint – Publishing Options
Selecting the Document Library option allows you to create a new Form Library on a SharePoint site, or update the form template associated with an existing Form Library. Fields in the form template can be promoted as columns in the Form Library, and SharePoint will automatically copy the values from forms filled out and saved to equivalent columns in the SharePoint Library. Document Libraries are the most common way to publish InfoPath form templates. After clicking Next, choose to either create a new library on SharePoint or to update an existing library. If you choose to create a new document library, clicking Next will allow you to enter a name for the new library. If you choose to update the form template in an existing library, select the library to update.
Next, select the fields to promote as columns in the SharePoint library. Click the Add button to select the fields you want to appear as columns in the SharePoint document library.
Figure 96 Publish to SharePoint - Select fields to promote
After selecting the fields to promote as columns click OK and then click Next. Verify the information provided and if everything is correct, click Publish.
Figure 97 Publish to SharePoint – Publish
Site Content Type
If you wish to use the same form template in multiple form libraries on the same SharePoint site, you can publish your form template as a Site Content Type. This allows you to publish the form template to a central location on the SharePoint site. Then you can configure each form library you wish to use that same form template. This can be useful for management purposes.
After entering the URL of the SharePoint site you wish to publish the form template to and clicking Next, select whether you wish to create a new site content type or update an existing site content type and click Next.
Figure 98 Publish as Content Type
Next, specify the location where you’d like to place the form template. Unlike publishing to a form library, where the form template is placed in the form library itself, you need to specify where you’d like the form template to be stored. You should select a location on the SharePoint site somewhere, such as the Shared Documents folder, or a Document Library you create to store your site content types. Once you selected a location and a filename for your form template, click Next.
Just as with a form library, you can promote fields from your form as SharePoint columns. Add the fields you wish to promote and then click Next. Finally, confirm the publishing settings and click Publish to complete the publishing process.
Once you have published your form template, you can add it as a content type for a new or existing form library. First, browse to the library where you wish to activate the form template. From the Settings button, choose Form Library Settings. Select the Advanced Settings link. Set the option Allow management of content types to Yes and click Ok. You should now see a Content Types section in the Form Library Settings page. Click the Add from existing site content types link. From the Select site content types box, choose Microsoft Office InfoPath. Select the form template you just published and click the Add button. Finally, click Ok.
Administrator-approved form template (browser-enabled forms only)
Form templates that contain managed code may require full trust (and need to be digitally signed) and be deployed and activated by a server administrator. Administrator-deployed form templates are made available in a form template library for the entire site collection.
Figure 99 Administrator-approved form template
To publish a browser-compatible form as an Administrator-approved form template, click Next and enter or browse for a shared location which the Administrator can access.
Figure 100 Publishing for Admin deployment - Shared location
Clicking Next allows you to promote fields from the template as columns in the SharePoint library, and to select fields that will be used in web part connections.
Figure 101 Publishing for Admin deployment - Promote fields
The last screen of the wizard allows you to verify the Location, Target Site and Security Level and complete the process by clicking Publish. If any changes need to be made, click Back to make those changes. Once the form has been published provide the form name and publish location to the server administrator for upload and activation to the server.
To complete the deployment of a browser-compatible form template, the form must be uploaded to the server, activated to a Site Collection and set as a Content Type in a document library. Form templates can only be activated to site collections under Web applications where Microsoft InfoPath Forms Services has been provisioned.
From the Application Management tab on the SharePoint Central Administration page the Administrator will need to select the Manage Form Templates option in the InfoPath Forms Services section.
Figure 102 Manage Form Templates
By selecting the Upload form template link the Administrator can click on the Browse button to allow them to navigate to the location where the form was published.
Figure 103 Upload Form Template
At this point the Administrator can click the Verify button to insure there are no errors with the published form. By clicking the Verify button the server administrator executes the same process as the form developer when they use the Design Checker to validate the form against a server. If there are any errors that would cause the form template to fail in a forms services environment they will be reported to the server administrator.
In addition, the Administrator has other options if the template to be uploaded has previously been deployed. If the Upgrade the form template if it already exists option is enabled the Administrator can choose the action that will occur for users that have this form open in a browser.
Figure 104 Verify Form Template Results
Once the Administrator has verified the form and clicked OK they are returned to the Upload Form Template page where they will need to re-select the form template. Click the Upload button to upload the selected form template to the server.
The process of deploying a template places the template in its own directory in the Features directory on the server. The templates live on the Web Front End’s but will be “ghosted” to appear as items in the Form Template Library. Ghosting enables the same items to be present in multiple locations and this avoids a roundtrip to the database since the templates live on the Web Front Ends.
At this point, the form template has only been uploaded to the server – in order to use this template in a document library the form template must first be activated to a Site Collection.
Click on the form template that was just uploaded and choose Activate to a Site Collection.
Figure 105 Activate to a Site Collection
After selecting Activate to a Site Collection, the Administrator will need to select the appropriate server for activation and click OK.
Upon successful activation, the Administrator is returned to the Manage Form Templates page. The last step in completing the process is to make that template available to a document library. To utilize the form template in a document library, the server or site collection administrator will need to add the form template as a new Content Type to the document library. See the Site Content Type section for more information on adding the form template as a new content type.
Publish to a list of e-mail recipients
If you want your user’s to have their own copy of the form template, you can choose to publish the template to a list of e-mail recipients. After selecting this option and clicking Next, enter a unique and friendly name for the template – this is what users will see as the subject line of their e-mail.
Figure 106 Publish to E-mail - Template name
After clicking Next, click the Add button to select the fields to promote as columns in an Outlook folder.
Figure 107 Publish to E-mail - Select fields to promote as columns
Click OK to return to the Publishing Wizard and then click Next and Publish to complete the publishing process. This will launch a new e-mail message with the default view as the body of the message and the form template as an attachment.
Figure 108 Publish to E-mail – Publish
Enter any text you want in the Introduction field, enter or select the recipients and click Send.
When sending updates to forms in e-mail, there are some circumstances where the user will see the following overwrite error:
Figure 109 Advisory dialog when Form ID matches one already in the cache
This happens when the Form ID of the form sent to the user matches the Form ID of a form already on their computer and all of the following conditions are not met:
The forms have the same Access Path
The forms were opened from the same location
The forms are signed by the same certificate
Publish to a network location
If you want to publish an InfoPath form template to a shared network location, but don’t need to make use of any of SharePoint’s available functionality, select To a network location and click Next.
Figure 110 Publish to a network location
Enter the UNC path, including form template name, or click the Browse button to select the shared location and click Next.
Figure 111 Publish to a network location - Enter shared location
Occasionally, you may wish to publish the form template using one file path, but users will access the form template using a different file path. For example, you might publish the form template to a UNC file share that maps to a virtual directory in IIS. Users would browse to the form template using the web address of the virtual directory. If the users need a different access path for launching the form, enter it in this screen of the Publishing Wizard and click Next. If the users will access the form template using the same path, then leave this address the same and click Next.
Figure 112 Publish to network location - Alternate access path
Confirm the options selected and click Publish.
Figure 113 Publish to a network location – Publish
Publish as an installable form template (InfoPath 2007 only)
This option in the Publishing Wizard replaces the need to run the Regform tool to create an install package for the form template. If you do not have access to a digital certificate to sign your template but it needs to have the Full Trust option set, creating an install package so users can install the form template will provide this functionality.
Figure 114 Publish as an installable template
After clicking Next, select whether to create a Jscript (js) file or a Microsoft Installer (msi) file to install the form template. Enter your company name, select the appropriate language (this determines the language used on the setup screens) and click Next.
Figure 115 Publish as an installable template - select package type
Enter or click Browse to provide a location to create the install package and click Next.
Figure 116 Publish as an installable template - enter package location
In Microsoft Office InfoPath, you can convert forms created in Microsoft Office Word or Microsoft Office Excel into Office InfoPath form templates. (For additional information on importing forms, see the Import Forms section.) You can also design browser-compatible form templates or form templates that are designed to work in multiple versions of InfoPath.
When you do these things, however, you may encounter compatibility issues or other problems. For example, because InfoPath does not support bookmarks, they are removed during the process of importing a Word form. Similarly, certain InfoPath features are not supported in browser-compatible form templates and must be removed before you publish the form template.
The fastest way to find problems in your form template is by using the Design Checker task pane. You can then correct the problems before publishing your form template.
The Design Checker task pane allows you to:
Find compatibility problems that may exist in your form template. In some cases, InfoPath automatically fixes the problem for you and simply notifies you of that fix. In other cases, you will have to fix the problem manually. For example, to successfully publish a browser-compatible form template, you may need to remove an unsupported control or replace it with a different control.
Change the compatibility setting for the form template. For example, if you're currently designing a form template that works only in InfoPath, you can click Change Compatibility Settings in the task pane and choose to create a browser-compatible form template instead. Conversely, you can change a browser-compatible form template to one that only runs in InfoPath. Whenever you change compatibility settings, the errors and messages in the Design Checker task pane update accordingly.
InfoPath automatically checks for problems whenever you:
Import or open a form template in Design View
Change the compatibility setting for a form template
Save or publish a form template
Figure 117 Design Checker Task Pane
By reviewing the text at the top of the task pane, you see that the form template is currently compatible with both InfoPath 2010 and a server running InfoPath Forms Services. If you want to change this setting, click the Change Compatibility Settings… link.
The errors shown above are because the browser-compatible form template contains unsupported controls. To successfully publish this form template, those controls would need to be removed or replaced with compatible controls.
You can update the list of errors and messages in the Design Checker task pane at any time by clicking the Refresh button at the bottom of the task pane.
NOTE: Errors and Messages from an import process are stored in an XML Resource file. The only way to update the Design Checker task pane is to delete the XML Resource file. As such, clicking the Refresh button does not have an effect on Errors and Messages resulting from an import process.
Errors vs. messages
When you design a form template, you may encounter both messages and errors. You must fix errors to successfully publish your form template. You may optionally fix “messages.“
The following table describes the difference between errors and messages in the Design Checker task pane.
The form template will not function correctly, and the errors must be addressed before you can publish the form template.
The form template may not function as expected. Messages are for your information. You can choose whether to make corresponding fixes before you save or publish the form template.
Circumstances under which InfoPath checks for problems:
Type of problem
Office InfoPath 2010 form templates that are designed to be displayed and filled out in Web browsers are said to be browser-compatible. Browser compatibility problems occur when you use an InfoPath control or feature that is not supported in browser-compatible form templates. When your first design a form template, you specify a number of options in the Design a Form dialog box, including whether to make the form template compatible with a server running Microsoft InfoPath Forms Services. If you select the Enable browser-compatible features only check box in the Design a Form dialog box, you won't generally see browser compatibility errors in the Design Checker task pane. That's because unsupported features and controls are automatically hidden or inaccessible in design mode. However, if you decide to switch from designing a client-only form template to one that also works in a browser, then you may see compatibility errors in the Design Checker task pane.
Office InfoPath 2010 form templates that also work in InfoPath 2003 are said to be backward-compatible. Backward compatibility problems occur when you add a control or feature to your form template that won't work in earlier versions of InfoPath. Unless you are designing your form template to work in a mixed environment — that is, one where some users have the latest version of InfoPath and some are still using InfoPath 2003, most Office InfoPath 2010 form templates don't need to be compatible with InfoPath 2003. Therefore, Office InfoPath 2010 automatically hides backward-compatibility errors and messages in the Design Checker task pane. To enable this functionality, click the Change Compatibility Settings link in the Design Checker Task Pane and enable the option Show report on compatibility with InfoPath 2003. (You can also enable this functionality by choosing Form Options from the Tools menu and selecting the Compatibility category.)
You see errors and messages by default only when you open an InfoPath 2003 form template in Office InfoPath 2010 design mode or when you select InfoPath 2003 Form Template in the Save as type list in the Save or Save As dialog box. In all other circumstances, you must manually choose to show backward-compatibility errors and messages in the Design Checker task pane.
Import problems may occur after you import a form from another program, such as Word or Excel, and InfoPath tries to import features that it doesn't support. In some cases, InfoPath removes the unsupported feature whereas in other cases, InfoPath replaces an unsupported object with a placeholder image. You can then remedy the problem, either by removing the placeholder image from the form template or by reinserting the object, if that's possible. There are also cases where some features (such as hyperlinks, header and footer formatting, etc.) are neither removed nor replaced, but will degrade.
In offline mode, users can continue to work with forms, even when they cannot connect to data sources. The data connections that retrieve data from the data source continue to work offline, with some exceptions. Those exceptions are noted in the Design Checker task pane.
If your form template contains an outdated template part, the Design Checker task pane alerts you that an update to the template part is available.
Binding issues often occur when two or more controls are bound to the same field or group in the Data Source task pane, or when there are unbound controls on a form template. If binding issues are serious enough to prevent you from publishing your form template, such as unbound controls, then they will appear in the Design Checker task pane. If binding issues are less serious, you won't see an error or message in the Design Checker task pane, but you can move your mouse over the control to see the binding error.
View errors and messages from a server running InfoPath Forms Services
If you would like to view potential server-generated errors and messages in the Design Checker task pane before publishing a form, you can specify a server location in the Compatibility section of the Form Options dialog box. When you do this, InfoPath automatically displays errors and messages from the server in the Design Checker task pane. You can then review all compatibility problems for a browser-compatible form template at the same time, while you are designing the form template. Server-generated errors and messages appear under distinct headings in the Design Checker task pane so that you can locate them easily.
NOTE: If you would like to review Browser Optimization Messages in the Design Checker task pane, enable this option by clicking the Option button on the Design Checker task pane and selecting Show Browser Optimization Messages.
InfoPath Forms Services
Microsoft InfoPath Forms Services allows InfoPath forms to be accessed using a supported web browser, provides a central location to store and manage form templates for an organization and it enables people to fill out forms by using a Web browser. You can create forms using the InfoPath designer and deploy forms by hosting them on a server running Microsoft InfoPath Forms Services using the publishing wizard.
This SharePoint-based technology extends the functionality you get by using InfoPath alone by making it easier to give customers, partners and suppliers access to forms you have created. When you use Microsoft InfoPath Forms Services with InfoPath, you can gather information and share, reuse and repurpose it in your team or organization or with users outside of your organization.
Extend the reach of your form templates
Prior to InfoPath 2007, users who filled out InfoPath forms needed to have InfoPath installed on their computers. With Microsoft InfoPath Forms Services, all that’s needed is a Web browser. When you design a form template in InfoPath 2007 and later, you can select a compatibility setting that enables you to design a browser-compatible form template so users can fill out forms by using a supported Web browser such as Microsoft Internet Explorer, Apple Safari or Firefox. This extends the reach of your forms to users without InfoPath installed.
The user experience of filling out a form in a Web browser is similar to that of filling out a form in InfoPath. Much attention has been given to ensuring that the browser user has a good experience when filling out the form and features like field validation and some types of logic are all performed immediately in the browser without round-trips to the server. This results in a more responsive and reactive user experience.
Designing a form template for Forms Services in InfoPath 2007
If you are developing a new form template, you can choose to only include those features that are supported in both the rich client and browser mode by selecting the Enable browser-compatible features only option on the Design a Form screen.
Figure 118 Create a form template that can be filled out in a web browser
This is considered a “design once” experience since only those features that work in both environments are exposed to the developer.
If you have originally designed a form template for the rich-client only but want to “convert” that template for use in either environment you can use the Design Checker Task Pane to change the compatibility setting for your template.
Figure 119 Change form template compatibility
Clicking the Change Compatibility Settings... link on the Design Checker Task Pane launches the Form Options screen opened to the Compatibility category. Enabling the Design a form template that can be opened in a browser or InfoPath option and clicking OK will cause the Design Checker to scan the template and report any compatibility issues in the Design Checker Task Pane. Depending on the type of issue found by the Design Checker (e.g. invalid control, submit option, etc.), you may need to correct that issue before being able to publish the template.
Figure 120 Compatibility Settings
The Form Options Compatibility screen has these additional options:
Hide errors for code that uses InfoPath-only features: If you have code that is designed to execute in the rich-client only, enabling this option will suppress these errors from being displayed in the Design Checker Task Pane.
Enter the URL of a server that is running InfoPath Forms Services...: By entering a URL to a server running Microsoft InfoPath Forms Services, the Design Checker will also validate server-side issues such as browser rendering differences.
Show report on compatibility with InfoPath 2003: If you are developing a form template that needs to be compatible with InfoPath 2003, enabling this option will allow you to see functionality that may cause issues when the form is opened with InfoPath 2003 or saved in the InfoPath 2003 file format.
InfoPath “hides” those controls that are not compatible in a browser. To see what controls have been hidden, click the Some controls have been hidden based on the current compatibility settings message at the bottom of the Controls Task Pane. This will display a dialog displaying the hidden controls.
Figure 121 Hidden Controls
Designing a form template for Forms Services in InfoPath 2010 and 2013
By default, the InfoPath 2010 designer assumes that you wish to design a form template that is compatible with Forms Services. If you wish to enable client-only features, then choose a form template type specified for InfoPath Filler.
Figure 122 Client-only form templates
If you have originally designed a form template for the rich-client only but want to “convert” that template for use in either environment you can use the Compatibility section of the Form Options dialog to change the compatibility setting for your template.
Choose the form template type you wish to create. Note that if you have already done work designing your form template, you will need to run the Design Checker from the backstage screen to ensure that your current design is compatible with the form type you have chosen.
Form Template Browser options
There are various “browser” options available for browser-compatible forms: what toolbars should be visible, what buttons are displayed on those toolbars, how the form refreshes data, the form language and whether the form should include functionality for rendering on a mobile device. Selecting Advanced Form Options from the backstage menu and choosing the Web Browser category will allow you to customize these settings.
Figure 123 Customize browser settings
In addition, “post back” settings can be customized for each control on the View. By right-clicking on the control, choosing Properties and selecting the Browser Forms tab, post back settings can be set individually. (For additional information on post back see the Post Backs section.)
Figure 124 Control post back settings
When creating a browser-compatible form template, you have the same data sources available as when creating a rich-client form template. However, browser-compatible form templates do not support submitting directly to a database. If you need to support submitting data to a database via a browser-compatible form, a custom web service will need to be written to handle the manipulation of all of the data from the form.
Managing browser-enabled templates
Once a browser-enabled form template has been uploaded and activated to a site collection, there may be a need to update that template or remove that template entirely. If the template design or business logic needs to be changed, the developer needs to make that change in the locally saved copy and re-publish the form using the same steps as documented in the Deploying browser-enabled form templates section. The server administrator only needs to re-upload the same XSN and the design changes will be reflected the next time the form is opened.
Quiesce Form Template
If you want to be sure that user’s stop using the existing form template, the server Administrator can Quiesce the existing form template. This insures users that currently have the form open can complete their operation without interruption but no new instances of that form template can be created. In order for the quiescing process to initiate, the Administrator must enter a time (in minutes) at which time the form will be fully quiesced (offline.) The maximum value is 1440 (24 hours.) To re-enable the form for use, the Administrator will need to click the Reset Template button to allow new sessions again.
Figure Reset form template after quiescing
Deactivate Form Template
Deactivating a form template results in that template being unable to render in the browser or the client. Deactivating a form template should only be used when the developer or Administrator wants to remove that specific template from a Site Collection.
NOTE: Deactivating a template does not remove that template as a Content Type. As such, users can still select that content type for a document library; however, attempting to create a new form based on that template will result in an error.
Remove Form Template
As with deactivating a form template, removing a form template from a Site Collection does not remove that template as a Content Type. To fully remove a template from a site collection, the following steps must be completed:
Delete the content type from each form/document library
Delete the content type as a Site Content Type
Deactivate the template
Remove the template
These steps will insure the template cannot be used as a Content Type in any form/document library.
InfoPath Forms Services Configuration Options
After configuring an Office Server for InfoPath Forms Services, there are a number of configuration options available to the Administrator. To review these options navigate to the SharePoint Central Administration page, select Application Management and from the InfoPath Forms Services section choose Configure InfoPath Forms Services.
Figure 125 InfoPath Forms Services Configuration
User Browser-enabled Form Templates
Enable or disable the ability for users to publish form templates that can be viewed in the browser.
NOTE: If this option is disabled, when a form developer attempts to publish a browser-enabled template using the Publishing Wizard, they will see this message:
Enable or disable the ability of forms created by users for viewing in the browser to actually render in the browser.
NOTE: If this option is disabled, if users have InfoPath 2010 the form will open in the InfoPath client. However, if users do not have InfoPath 2010 and need to open this form in the browser they will see this error: “This form template is not currently browser-enabled. It must either be republished as a browser-enabled form, or opened using Microsoft Office InfoPath 2010.”
Data Connection Timeouts
Allows the Administrator to specify the default and maximum timeouts for data connections from browser-enabled forms. The connection timeout can be changed by code in the form template, but will never exceed the maximum timeout specified.
Data Connection Response Size
Allows the Administrator to specify the maximum size of responses data connections are allowed to process.
HTTP data connections
If data connections in browser-enabled form templates require Basic Authentication or Digest Authentication, a password will be sent over the network. Check this box to require an SSL-encrypted connection for these authentication types.
Embedded SQL Authentication
Forms that connect to data bases may embed SQL username and password in the connection string. The connection string can be read in clear text in the UDC file associated with the solution, or in the solution manifest. Uncheck this box to block forms from using embedded SQL credentials.
NOTE: If a developer has created a connection using embedded SQL Authentication and this option is not enabled, users will see this error: “An error occurred accessing a data source” when the browser form attempts to access the data source.
Authentication to data sources (non-admin-deployed form templates)
Data connection files can contain authentication information, such as an explicit username and password or a Microsoft Office Single Sign-On application ID. Check this box to allow non-admin-deployed form templates to use this authentication information.
Cross-Domain Access for User Form Templates
Form templates can contain data connections that access data from other domains (e.g. a web service or database on another server.) Select this check box to allow user form templates to access data from another domain.
Specify the thresholds at which to log error messages in the server logs.
Form Session State
Form session state stores data necessary to maintain a user session.
Post Backs (Refreshing data)
Forms designed with InfoPath will typically contain validation, calculations, expressions, rules and business logic (managed code) which need to be executed when the user fills out the form.
When the InfoPath client is used for filling out the form all this execution including managed code occurs on the client. Server round trips are only happening if the forms designer specifically requested them. One example here is the user enters an email alias in a text box and on tabbing out an event (i.e. Changing) executes managed code initiating a query to a directory on a server to pull the full name and other contact data and placing it in the appropriate text boxes.
When the user fills out a form in the browser only a subset of the execution is handled in the browser client via client side architecture. This architecture will push script files down from the Forms Server that will handle some of the basic validation, calculations, expressions and rules right within the browser. All managed code however will be executed on the server. Also any validation, calculation, expressions or rules that cannot be handled via client side architecture will require execution on the server which will cause a round trip.
As such, each control has three post back options: Never, Always and Only when necessary. By default, Only when necessary will be the selected option to minimize the number of trips to the server. If business logic requires, the developer of the form can customize this setting on a per-control basis.
Backup and Restore
Backup and Restore support is achieved through three separate mechanisms: Windows SharePoint Services (WSS), Volume Shadow copy Service (VSS) or SQL backup and restore. There are 4 levels of granularity at which data can be backed up and later restored:
Farm-level: Backing up the entire farm.
SSP-level (OSG-only): After OSG is installed, an entire SSP can be backed up or restored.
Web Application-level: An entire Web application can be backed up and restored.
DB-level: Every database can be backed up and restored individually.
For additional details on backup and restore see the Windows SharePoint Services Administration Guide.
InfoPath E-Mail forms
Microsoft Office InfoPath’s integration with Microsoft Office Outlook has been enhanced to help streamline the processes used to collaborate on and share data. With these added features, you can now open, fill out, and submit InfoPath e-mail forms directly in Outlook. If you receive an InfoPath e-mail form, you can reply to it, forward it, and store it just as you would with other items in Office Outlook.
To send or receive InfoPath e-mail forms in Microsoft Office Outlook, Office InfoPath 2010 must be installed on the computer and Outlook must be configured to send and receive InfoPath e-mail forms. If you have these programs installed, and Outlook is configured to send InfoPath e-mail forms but the same is not true for recipients of the InfoPath e-mail forms, the forms that you send will appear to those recipients as attachments to e-mail messages. The recipients can then save the attached forms and open them by using InfoPath.
Using InfoPath Forms folders to display data
By storing collections of related e-mail forms in InfoPath Forms folders in Office Outlook, you can organize and review data easily. For example, if you collect status report forms from your team, you can store the completed forms in an InfoPath Forms folder in your Inbox. Besides keeping all related forms in one place, you can also choose to show data from each form in columns in a custom view for that folder. This allows you to quickly group, filter, and sort data from multiple forms.
Before displaying data from a form in a view of an InfoPath Forms folder, the form template for that form must be configured to use property promotion. Property promotion enables fields in a form to display values in InfoPath Forms folders in Office Outlook, or on servers running SharePoint or Microsoft Office SharePoint Server. Only a form template designer can enable property promotion for a form template by using Microsoft Office InfoPath 2010.
Figure 126: InfoPath Forms folder with Promoted fields
InfoPath E-mail Actions
From within the InfoPath forms folder, you have all of the standard Outlook mail functionality: Reply, Reply All, Forward, Flags, Categories, etc.
Figure 127 InfoPath e-mail actions
Selecting Reply, Reply All or Forward, the InfoPath form opens in an InfoPath E-mail window with the InfoPath View as the body of the mail message. The data in this View is editable and the sender has the option of including the form template or just a snapshot (HTML) view of the data.
Figure 128 Reply, Reply All or Forward results
When the InfoPath Forms folder has been associated with a specific InfoPath template, you will see the New button contains an InfoPath icon. Clicking the New button produces a new, blank InfoPath form based on the template and includes the InfoPath e-mail feature of being able to “Forward” the new form via e-mail.
Figure 129 InfoPath from using the New button
If the InfoPath Forms folder has not been associated with a specific InfoPath template or you would like to create an e-mail from a different InfoPath template, click the arrow next to the New button and select Choose InfoPath Form.
Figure 130 Create a new form from an InfoPath template
Selecting this option launches the InfoPath Choose InfoPath Form screen and allows you to select any InfoPath form that has been cached on the machine or you can launch InfoPath (by choosing Open InfoPath) and open any form on your computer or begin designing a new form template.
Figure 131 Create a new form from an InfoPath template
Analyzing Form Data
When you have InfoPath forms stored in an InfoPath Forms folder, you can consolidate the form data in selected forms for data analysis or reporting purposes.
Select the forms you want to merge
Select Merge Forms from the Form Actions command on the ribbon
Figure 132 Merge Forms action
Selecting the Merge Forms option will launch InfoPath and the data will be merged into a new form based on the Merge settings defined in the associated form template. (For additional information on merging forms, see the Merge Forms section.)
Export forms to Excel
Select the form(s) you want to export to Excel
Select Export Forms to Excel from the Form Actions ribbon
Selecting the Export Forms to Excel option launches Microsoft Excel, creates a new Excel workbook, creates an XML Map and exports data from the selected InfoPath forms.
InfoPath will use the first InfoPath file selected to return the associated schema from the cached template. If the InfoPath form template is not available, Excel will create a schema based on the data in the form.
NOTE: This process exports all data in the selected forms (in a flattened format), not just data from the promoted columns.
Figure 133 Data from InfoPath forms
Export InfoPath e-mail forms as InfoPath XML files
If you would like to save the InfoPath forms in your InfoPath Forms folder to a location on disk, you can export them by choosing Export Forms from the Form Actions ribbon.
After selecting Export Forms, choose an existing (or create a new) folder to store the exported forms and click OK. This process simply exports the selected InfoPath forms as InfoPath XML files to the selected folder.
NOTE: As with all InfoPath XML forms, the exported forms will contain a pointer (href attribute) to the InfoPath template they were designed from. As such, if the InfoPath forms were created from a template that was not in a shared location, other users may not be able to open the exported forms.
InfoPath e-mail forms with Restricted Permissions
When an InfoPath form has had restricted permissions through Information Rights Management (IRM) applied, the content of the form is not visible in the Outlook Preview Pane. Instead the recipient will see the following message:
You have received an InfoPath form with restricted permission. To view the form, open the attachment, or click Open Form if you are using Microsoft Office Outlook.
Depending on the permissions granted to the user, data analysis as described above may or may not be available to that user.
For more information on IRM see the Information Rights Management section.
When designing a form, you can enable digital signatures so that users filling out your form can digitally sign the data. This signature confirms that the form originated from the signer and has not been altered. In addition, the signature can contain a comment from the signer. After being signed, the values in the form cannot be modified without invalidating the signature. If even a single character in the signed XML data is changed, the signature is invalidated and InfoPath will notify the user.
When designing a form, you can enable digital signatures for the entire form (client only) or for specific parts of the form. If you enable digital signatures for part of the form, you must determine which data in the form should be signed. You can additionally associate that data with a section in the form. When users sign the form, the digital signature locks the data so that it cannot be changed, and stores the view with the digital signature.
In addition, you can specify whether to allow multiple digital signatures for a form, and whether those signatures should be co-signed (in which case each signature is independent of the other signatures) or counter-signed (in which case each signature signs the form, as well as the signatures that precede it).
Note: You cannot enable digital signatures for a form that was designed based on an XML Schema that does not have a digital signature namespace.
To enable digital signatures in a form, click the Form Options command on the Tools menu and select the Digital Signatures category.
Figure 134 Digital Signature tab of Form Options Dialog
In addition to ensuring that the data in an InfoPath form is not changed after the user digitally signs it, InfoPath also captures additional information in the digital signature to verify the intention of the signer and to provide additional information about the form. InfoPath captures an image of the form view as it was presented to the signer when the form was signed, stored as a base64-encoded image in the standard PNG format. It also captures the system date and time of the transaction, the version of the OS used, the version of InfoPath used, and the screen resolution and the number of monitors on the machine used to sign. Like the form data, this additional information is part of the signature, and cannot be removed without invalidating the signature.
At any time, it is possible to recall this data by clicking on a signature in the form. This will display a dialog showing all the information stored in the signature, including the form view as the signer applied the digital signature.
Figure 135 Verify Digital Signature showing the data about the signature
Signing the Entire Form
By default, digital signatures are not enabled. To enable digital signatures for the entire form, choose the Enable digital signatures for the entire form option. If you wish, you can specify that InfoPath should prompt the user to sign the data if they attempt to submit the data without a signature. In this mode, when the user digitally signs the form, the entire form becomes read-only. Additional users can also digitally sign the data (counter-signing) but they cannot modify the data without invalidating all existing signatures.
Figure 136 Signing the entire form
Signing individual sections
You can also enable digital signatures for individual sections of the form. This can be useful in workflow scenarios where each user must fill out and digitally sign a portion of the form before moving the form along to the next person in the workflow chain. Selecting the Enable digital signatures data for specific data in the form option allows you to define regions of the form that can be signed separately. To specify which sections of the form use digital signatures, use the Add button to add new Signed data definitions.
Figure 137 Signed Data dialog using independent (co-sign) option
Start each Signed data definition by giving it a name. Next, use the Select XPath button to choose which fields or groups to sign. Be careful when using this command not to select a repeating field or group. Because of the nature of XML digital signatures, signing one repeating field or group in a form would digitally sign all of them. This would prevent you from adding or removing sections, or from changing the data.
For each Signed data definition, you can also define what kind of signatures you want. You can choose to allow only one signature. You can also choose to allow independent signatures. This might be useful in a scenario where one user fills in a section and signs it, and another user comes along later and changes the data and re-signs it. This would invalidate the first user’s signature, but not the second. Finally, you can allow counter-signing, where each signature signs the preceding signatures. This might be useful in a scenario where each user in the workflow must confirm that they have examined the data signed by previous users.
You can also specify a specific message that is shown to the form fillers as they are signing the form.
Additional Digital Signature Options
In the Properties dialogs of Section and Optional Section controls, you will find a Digital Signatures tab.
Figure 138 Form Section Properties box, Digital Signatures page
This dialog tab allows you to enable digital signatures for a section. You can also control whether a section becomes read-only when it is digitally signed (turn this off to allow independent digital signatures), and whether to display an icon in the form to display digital signatures on the section.
Protecting a Form Template from Accidental Changes
The presentation of a form in InfoPath, with its rich environment and views, is linked to the form template attached to that form. Changes to the form template can result in unexpected changes to the way data is presented to the user, and can lead to actual or perceived data loss or corruption. For this reason, it is important to protect InfoPath form templates against accidental modification.
To help provide this protection, InfoPath monitors changes made to a form template’s XML Schema. If a change is made that will break existing forms and is then saved back to the original form location, InfoPath displays a warning that the change could result in data loss or errors. Two changes that can produce this warning are:
Adding new required fields (attributes or elements) to the XML Schema
Removing fields or groups from the XML Schema
Form Template Versioning
InfoPath also provides automatic form template versioning to help protect forms. This consists of a version number that has four parts: Major, Minor, Revision, and Build (for example 220.127.116.11). Whenever a change is made to a form and then saved, InfoPath automatically increments the Build part of the version number. You can also manually set all four parts of the version number on the Versioning category page of the Form Options dialog box (available from the Tools menu) while in design mode.
Figure 139 Set the version number in the Form Options dialog box
When a new form is created from the form template, the version number is included within the form’s underlying XML file. Later, when the form is re-opened, InfoPath compares the version numbers of the form template and the form. If they’re different, InfoPath provides several options. If the version number of the form is higher than the version number of the form template, this usually indicates that you have an old cached version of the form template. InfoPath tries to retrieve and open a current version of the form template from the original location. If this attempt fails, InfoPath displays a warning that the version number of the form is higher than that of the form template, and asks if you want to continue to open the form.
If the version number of the form is lower than the version number of the form template, the default action is for InfoPath to automatically upgrade the form to the current version by applying an upgrade XSL transform. However, you can also choose to have InfoPath do nothing, or you can handle the situation through script using the VersionUpgrade event. This might be a useful option when you have made a change to the form template that will keep existing forms from working with the new form template, or because you wish to provide new or calculated default values to new fields.
If InfoPath encounters a problem while in edit mode and stops responding, you can close the program in a controlled manner. The files you were working on are analyzed for errors, and the information in them is recovered if possible. The next time you launch InfoPath, the Document Recovery task pane will be displayed to list all the files that were recovered when the program stopped responding. The Document Recovery task pane allows you to open the files, view what repairs were made, and compare the recovered versions. You can then save the best version and delete the other versions, or save all of the open files to review later.
Figure 140 Document Recovery Task pane
Following the name of the file will be a status indicator, which shows how the file was recovered. Original indicates that the file was recovered from a manual save, and probably represents good data. Recovered indicates the file was recovered from memory during the recovery process or from the Auto Recover save process. Data in a Recovered file should be checked for accuracy and validity.
You can further help protect your work by using the Auto Recover feature to periodically save a temporary copy of the file you're working on. The Auto Recover save interval is, by default, set to perform an Auto Recover save every 10 minutes. This default can be changed by opening the Options dialog from the Tools menu and selecting the Advanced tab. With Auto Recover on, if an Office or Office family program stops responding while you have files open, you can use the Microsoft Office Application Recovery dialog box and recovered files will be displayed in the Document Recovery task pane. The data in the files reflects the last time Auto Recover saved the files. Note: Auto Recover should not be used as a substitute for manually saving or backing up your files.
InfoPath enables the form designer to prevent users from accessing selected commands and shortcuts. This is useful when designing a form with a specific workflow in mind, to prevent users from accidentally breaking the workflow. By opening the Form Options dialog from the Backstage environment and selecting the Filler Features category, you can disable:
Save and Save As
Export to Web
Export to Microsoft Office Excel
Export to PDF or XPS
Send to Mail Recipient
Auto save (Auto Recover)
Figure 141 Filler Features
InfoPath allows users to export forms as they are being filled out in several different formats to help them analyze or work with data in different ways.
InfoPath includes the ability to send a form as an e-mail message. On the File menu, click Save & Send and then click Send Using E-mail. When you send an InfoPath form in an e-mail message, an Introduction field is included in the header so that you can give the recipient any additional information they may need to know about the form. When you are satisfied with the e-mail, click Send. By default the form data and the associated form template are sent to the email recipient as an attachment. If you would prefer to not include the template, you can disable this option before sending the e-mail by unchecking the “Include Form Template” option in the Mail Options Task Pane. The current view of the form is also included in the body of the email message, so that users who do not have Microsoft Office InfoPath installed can still see the form data.
Figure 142 Send Using E-mail
Note: Microsoft Office Outlook must be installed for this feature to be available.
Export to the Web
InfoPath provides functionality to save a file as a .mht (Web archive) file. This file can be viewed in many Web browsers and can be opened in Microsoft Word. On the File menu, click Save & Send and then click Export to Web. In the Export to Web dialog box, enter a name for your file in the File name box, choose a location and then click Export.
NOTE: The Export to Web command does not allow users who do not have InfoPath installed to edit or fill out an InfoPath form. Instead, it creates a read-only HTML-based presentation of the form, similar in form and function to the body of an email produced by the Send to Mail Recipient command.
Export to Excel
InfoPath can export data from an open form and additional forms to Microsoft Excel. This feature exports either the data available in the current view or all form data as a table in Excel. The exported document is a table with the selected form fields as columns, and the data as rows in the table. You can use this feature to:
Analyze your data in Excel Whether you have a single form with a large table or data gathered in many forms, you can leverage all of the data you have collected with InfoPath and analyze it with all of the functionality of Excel.
Work with the data in hundreds of forms After collecting hundreds of forms full of data, you may want to be able to view all of the information in one view. You can export all of those forms to Excel and work with them in a single view.
Convert hierarchical XML data to a flattened list Although XML is very useful for creating readable data types, sometimes you want to flatten all of your data, viewing the high-level information side-by-side with the line items in a list or repeating table. You can export the hierarchy to a spreadsheet table for a flattened representation of the data.
The Export to Excel Wizard, launched from the File -> Export To -> Microsoft Office Excel menu when filling out a form, walks the user through the steps of exporting one or more forms to Excel.
To begin using the wizard, choose the type of data to export. This function will perform a flattened, rectangular mapping of the data.
Figure 143 Choose data to export
If you choose the option: Only form data from the current view, including this table or list all of the fields available to export will be shown and the user can select which of the fields to export. The fields shown in the following illustration are the fields in the current view, in the order in which they appear in the view.
Figure 144 Select data to exportChoose the forms from which to export data. This step allows the user to add additional files to the export. (NOTE: The additional forms must be based on the same template.)
Figure 145 Select forms to export
The data from the exported files is mapped so that each selected field is a column in the Excel table, and each element at the deepest level of data specifies a single row.
InfoPath also has the ability to export the current view to either PDF or XPS format. If your form contains multiple views you can either export each view individually or create a “summary” view that would be used for exporting to one of these formats.
The XPS format is a paginated representation of electronic paper described in an XML-based format. The XPS Document format is an open, cross-platform document format that allows customers to effortlessly create, share, print, and archive documents. In order to view these types of documents, an XPS Viewer must be installed.
To export to PDF or XPS, choose the Publish as PDF or XPS command on the Info tab of the File menu.
When a user has completed filling out a form, they can submit it through several processes. As discussed in the Creating a New Form from a Data Source section, InfoPath can submit forms to Web Services, Databases and pre-defined connections in a SharePoint Data Connection Library. In addition, InfoPath provides three other mechanisms for submitting forms:
Submit to SharePoint
Submit via E-mail
Submit to Host Environment
Enabling Form Submission
For most forms, submitting is not enabled by default. To enable submitting forms in InfoPath 2007, choose the Submit Options… command on the Tools menu. In InfoPath 2010 and 2013, click the Submit Options button on the Data ribbon. This will display the Submit Options dialog. Select the Allow users to submit this form option to enable submitting forms.
Figure 146 Submitting Forms dialog
Once you have enabled form submission, choose how you want to submit the form from the Send form data to a single destination dropdown list box. This list will display all of the available submitting options for your form. Next choose a data connection to submit your form to from the Choose a data connection for submit list, or click the Add… button to launch the Data Connection Wizard and create a new data connection.
Submit to SharePoint Data Connection
The submit option SharePoint Document Library data connection allows users to submit their forms directly to SharePoint.To create a SharePoint Document Library submit connection, Select Data Connections from the Tools menu. This will display the familiar Data Connections dialog. Click the Add… button to launch the Data Connection Wizard. Select the Create a new connection to option, select the Submit data option and then click Next. Select the To a document Library on a SharePoint site option and then click Next.
Figure 147 Submit to a SharePoint form library
Specify the URL to a SharePoint form library. For example, to submit to the “Shared Documents” form library, you would specify a URL like “http://Server/InfoPath/Shared Documents”. Also specify a File name for the form. This can be a static value, or you create an expression to generate the file name by clicking the expression button. Note that this file name will only be used if the form has not been saved before. If you open an existing form and submit, the form’s current file name will be used.
Figure 148 Specify a library and file name
Notice the Allow overwrite if file exists checkbox. If this option is checked, then InfoPath will automatically overwrite any file with the same name as the one you’ve provided. This can be useful in scenarios where users will work with existing documents and then submit their changes back to the SharePoint form library. If you do not want users to be able to overwrite existing files, clear this checkbox.
Click Next and provide a name for the new data connection. It’s a good idea to give the connection a descriptive name so it’s easy to identify later. This is also your opportunity to confirm the settings for your data connection. If you notice a problem, click the Back button and correct the issue before continuing. When you are satisfied with the data connection, click Finish.
Figure 149 Summary of SharePoint data connection
Submit through Email Data Connection
The Submit via Email data connection allows users to submit their forms through e-mail if they have Microsoft Office Outlook. This can be a useful option as part of a workflow scenario or for ad-hoc collaboration. To create a Submit via Email adapter, Select Data Connections from the Tools menu. This will display the familiar Data Connections dialog. Click the Add… button to launch the Data Connection Wizard. Select the Create a new connection to option, select the Submit data option and then click Next. Select the As an e-mail message option and then click Next.
Figure 150 Submit as e-mail message
Specify the To, Cc, and/or Bcc recipients or create an expression to generate the recipient names by pressing the expression button to the side of each recipient field. Also specify the Subject or create an expression to generate the Subject by pressing the expression button to the side of the Subject field. If you wish, you can provide a static introduction for the form. Users will see this introduction at the top of the body of the email they receive when the form is submitted.
Figure 151 Specify the details of the e-mail
Click Next to select the attachments to send with the form.
Just as when a form is sent with the Send to Mail Recipient command, when a form is submitted through email, the XML data is included as an attachment to the email. Using the Attachment Name option, you can specify what the name of this attached file should be. In addition, you have the option to include the template for the form to ensure the users can open the form.
If you do not want to send an attachment, you can choose the option Send only the active view of the form and no attachment. In this case, the user will receive only an HTML representation of the View.
Figure 152 Submit via E-mail attachment options
Click Next and provide a name for the new data connection. It’s a good idea to give the connection a descriptive name so it’s easy to identify later.
This is also your opportunity to confirm the settings for your data connection. If you notice a problem, click the Back button and correct the issue before continuing. When you are satisfied with the data connection, click Finish.
Submit to Hosting Environment
The submit to Hosting Environment option is used in conjunction with the Form Control (for use in custom Windows Form applications) and the XmlFormView control (for use in custom ASPX pages.) Both of these controls are used to host InfoPath forms and support many of the same events and functionality. By selecting the Submit to the Hosting Environment option it allows developers to handle the submission of the InfoPath form in their custom application and take a custom action designed in the host application. (For more information on hosting InfoPath forms in a custom application see the Hosting InfoPath Forms section.)
To enable a Windows form to handle the submit event from an InfoPath form loaded in a Form Control:
Implement ISubmitToHostEventHandler on the Windows form
public partial class Form1 : Form, ISubmitToHostEventHandler
In the Window forms load event, instantiate the event handler
Add the event
public int SubmitToHostEventHandler(object sender, string AdapterName, out string ErrorMessage)
//Write your code here
To enable a custom ASPX page to handle the submit event from an InfoPath form loaded in the XmlFormView control:
Add the OnSubmitToHost attribute to the XmlFormView control object to call a custom function:
Add the custom function to the page:
private void OnSubmit(object sender, SubmitToHostEventArgs e)
InfoPath offers several options for how the form should behave after it is submitted. You can access these options by clicking the Submit Options… button from the Tools menu and selecting the Advanced button. This will display the Submit Options dialog.
Figure 153 Advanced Submit Options
It is important to distinguish between submitting a form and saving it. When the user submits a form, the data from the form is submitted using whatever data connection you have selected. However, the data is also still stored in the local file the user is currently viewing. Therefore, when the user closes the form, they will be prompted to save any changes they may have made. To avoid this, you can select the Close the form option in the Submit Options dialog. If form submission is successful, then InfoPath will automatically close the form without prompting the user to save changes. You can also use the Create a new, blank form option to have InfoPath automatically launch a blank copy of the form the user just completed after successful submission. If form submission fails for any reason, these options are ignored and the current form is left open for the user.
You may wish to change the default success and error messages for form submission to report additional information to your user. You can do so by enabling the Use custom messages option. If you select this option, whatever static text you provide will be displayed to the user instead of the default success or failure messages.
InfoPath Events and the Programming environment
Even with all of the customization available through InfoPath’s user interface, there may still be circumstances where it is necessary to write custom code for a form template. For this reason, InfoPath offers a rich object model for form template developers to use to create custom functionality.
The default programming environment for InfoPath 2007 is Visual Studio Tools for Applications (VSTA), with C# and VB.NET as the programming languages used in VSTA to create custom business logic for a form. You can also use Microsoft Visual Studio to create custom logic. InfoPath 2010 also offers the VSTA environment, but Visual Studio is not available. InfoPath 2013 no longer offers the VSTA programming environment. To create custom logic in InfoPath 2013 forms, you must use Visual Studio 2012.
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.
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 sections describe the events that InfoPath provides.
The Loading Event
The Loading event is used to initialize the form as it is being opened. You can use this event to set the appropriate view based on the data in the form or other conditions such as the current user. InfoPath passes a LoadingEventArgs object to the Loading event, which can be used to access the underlying XML document of the form and to indicate the success or failure of the load operation.
To add the Loading event handler to an InfoPath form, point to Programming on the Tools menu, and then click Loading Event.
The ViewSwitched Event
The ViewSwitched event fires when an InfoPath form is switched from one view to another. You can use this event to insert data into the form or to configure a custom task pane or other resource appropriately for the new active view. InfoPath passes a ViewSwitchedEventArgs object to the ViewSwitched event, which can be used to access the underlying XML document of the form.
To add the ViewSwitched event handler to an InfoPath form, point to Programming on the Tools menu, and then click View Switched Event.
The Changing, Validating, and Changed Events
As discussed in the Data Validation section, the Changing, Validating, and Changed events are used to validate data as it is entered into the form and to produce any desired side effects for that data. InfoPath passes either an XmlChangingEventArgs, XmlValidatingEventArgs or XmlEventArgs (respectively) object to these events, which contains information about the XML node during the change. These objects also provide access to the underlying XML document and the return status of the method and for the Changing and Validating events, include a method for raising an inline alert.
The Submit Event
The Submit event is fired when the submit operation is invoked either from the InfoPath user interface or by using the Submit method of the XMLForm object in the InfoPath object model. It can be used to perform a custom submit operation in lieu of InfoPath’s built-in submit functionality. InfoPath passes a SubmitEventArgs object to the Submit event, which can be used to access the underlying XML document of the form and to indicate the success or failure of the submit operation.
To add the Submit event handler to an InfoPath form, click Submit Options on the Tools menu. In the Submit Options dialog box, select the Perform custom action using code option. Click the Edit Code button to open VSTA with the new Submit event handler.
Figure 154 Submitting through custom code
The VersionUpgrade Event
The VersionUpgrade event is fired when a form is opened and the version number saved in the form is lower than the version number of the form template of the form being opened. It can be used to update the data and structure of the form to comply with any changes that have been made since the form was last saved. InfoPath passes a VersionUpgradeEventArgs object to the VersionUpgrade event, which provides a reference to the form’s underlying XML document, the document and form template version numbers, and the return status of the VersionUpgrade event.
To add the VersionUpgrade event to an InfoPath form, click Form Options on the Tools menu and select the Versioning category. Select Use custom event in the On version upgrade list and then click Edit to open VSTA with the new VersionUpgrade event.
Figure 155 Adding a VersionUpgrade event handler
The Clicked Event
The Clicked event is used to respond to a button on a form being clicked. InfoPath passes a ClickedEventArgs object to the Clicked event, which contains a reference to the form’s underlying XML document, the return status of the Clicked event, and the XML node that contains the button that was clicked.
To add the Clicked event handler to a form template, right-click the button whose Clicked event you want to handle and click Button Properties on the shortcut menu. In the Button Properties dialog box, click Edit Form Code.
Figure 156 Adding an OnClick event handler
The ContextChanged event
The ContextChanged event occurs after the context node changes. The context node is the XML DOM node mapped to the view which corresponds to the container (or item) with the current XML current selection. For example, if the current selection in the view is within a Text Box control, the context node is the node to which the Text Box is bound. If the current selection is a Repeating Section item, the context node is the node for that item. If two Repeating Section items are selected, the context node is the ancestor XML DOM for both items node mapped into the view (starting at the current selection and walking up through the view ancestors to the BODY tag). Note that the ContextChanged is asynchronous – it does not fire on every change in context node, it instead fires after the application has stopped processing other events.
This example puts contextual help specific to the context node into the body of the custom task pane.
var oContextNode = eventObj.Context;
var strText = "";
if( oContextNode.nodeName == "my:root" )
strText = "";
else if( oContextNode.nodeName == "my:singleName" )
strText = "Type your full name.";
else if( oContextNode.nodeName == "my:webSite" )
strText = "Type the Web address of your personal web page.";
var oTaskPane = XDocument.View.Window.TaskPanes.Item(0);
oTaskPane.HTMLDocument.body.innerText = strText;
public void FormEvents_ContextChanged(object sender, ContextChangedEventArgs e)
if (e.ChangeType == "ContextNode")
// The XML selection or context has changed.
XPathNavigator oContextNode = e.Context;
string strText = "";
if (oContextNode.Name == "my:myFields")
strText = "";
else if (oContextNode.Name == "my:singleName")
strText = "Type your full name.";
else if (oContextNode.Name == "my:webSite")
HtmlTaskPane oTaskPane = (HtmlTaskPane)this.CurrentView.Window.TaskPanes;
mshtml.HTMLDocument oDoc = (mshtml.HTMLDocument)oTaskPane.HtmlDocument;
oDoc.body.innerText = strText;
oContextNode = null;
oTaskPane = null;
oDoc = null;
The Merge event
The Merge event fires when the Merge Forms… command on the File menu is selected or the MergeForm method of the XMLForm object is called. The Merge event is used to provide additional processing before a form has been merged with another form as this event occurs before data is imported from another form. InfoPath passes a MergeEventArgs object to the Merge event, which can be used to access the underlying XML document of the forms being merged.
To add the Merge event to an InfoPath form, click Form Options on the Tools menu and select the Advanced category. Select the Merge using custom code option and click the Edit button to open VSTA with the Merge event.
If the CancelableArgs.Cancel property of the MergeEventArgs object is set to true (
mk:@MSITStore:C:\\Program%20Files\\Microsoft%20Office%202003%20Developer%20Resources\\Microsoft%20Office%20InfoPath%202003%20SDK\\Help\\infref.chm::/html/xdproReturnStatus_3.htmReturnStatus property of the MergeEvent object set to false in 2003), InfoPath cancels the merge operation. If an error occurs in the code for the Merge event handler, InfoPath ignores it and relies on the CancelableArgs.Cancel property of the MergeEventArgs object. If the CancelableArgs.Cancel property is not explicitly set, the default value of true is used.
In the following example, the Merge event handler is used to merge using existing InfoPath merge functionality, but also set a property before and after the merge completion to denote that merge is occurring.
var g_fMerging = false;
// Set global property that merging is occurring
if (eventObj.Index == 0)
g_fMerging = true;
eventObj.ReturnStatus = true;
if (eventObj.Index + 1 == eventObj.Count)
g_fMerging = false;
XDocument.UI.Alert("Your merge of " + eventObj.Count + " file(s) is now complete.");
public void FormEvents_Merge(object sender, MergeEventArgs e)
// Write your code here.
e.CancelableArgs.Cancel = false;
if (e.Index + 1 == e.Count)
//The merge was successful
MessageBox.Show("Your merge of " + e.Count + " file(s) is now complete.");
The Save event
The Save event fires when the save operation is invoked either from the InfoPath user interface or by using the Save or SaveAs method of the XmlForm object in the InfoPath object model. This event allows you to write code that saves a form using a custom process. If the CancelableArgs.Cancel property of the SaveEventArgs object is set to true (ReturnStatus property of the Save event object set to false in 2003), InfoPath cancels the save operation. If an error occurs in the code for the Save event handler, InfoPath ignores it and relies on the CancelableArgs.Cancel property of the SaveEventArgs object. If the CancelableArgs.Cancel property is not explicitly set, the default value of False is used.
The CancelableArgs.Cancel property works in conjunction with the CloseIfSaveCancelled property when the InfoPath form is closing. If the document is dirty and Return fails because the user cancelled, the CloseIfSaveCancelled property can be set to true to allow InfoPath to continue closing. Otherwise, InfoPath will not close with the document dirty.
//We can use the "Submit" data connection setup to SharePoint to perform
eventObj.ReturnStatus = false;
eventObj.ReturnStatus = true;
public void FormEvents_Save(object sender, SaveEventArgs e)
//We can use the "Submit" data connection setup to SharePoint to perform
catch (Exception ex)
e.CancelableArgs.Cancel = true;
e.CancelableArgs.Cancel = false;
The Sign event
The Sign event fires after a set of signable data has been selected to sign. You can use this event to add additional data to the digital signature. For example, you can add data from a trusted timestamp server, or add a server-side countersignature of the transaction. You can also use this event to block signing if the current user is not a member of a particular group.
In the following example, the Sign event object is used to add a signature and comment to a SignedDataBlock object:
// The OnSign handler can be customized only in fully trusted form templates.
var Signature = eventObj.SignedDataBlock.Signatures.Create();
// Countersign the signature with some extra data
// Get the XML node storing the signature block.
var oNodeSig = Signature.SignatureBlockXmlNode;
var oNodeSigValue = oNodeSig.selectSingleNode(".//*[local-name(.)=’signatureValue’]");
//Add the value returned from the timestamping service to the
//unsigned part of the signature block.
var oNodeObj = oNodeSig.selectSingleNode(".//*[local-name(.)=’Object’]");
var oNode = oNodeObj.cloneNode(false);
oNode.text = “Example test data”;
public void FormEvents_Sign(object sender, SignEventArgs e)
//Create a new signature object
Signature thisSignature = e.SignedDataBlock.Signatures.CreateSignature();
XPathNavigator oNodeSig = thisSignature.SignatureBlockXmlNode;
XPathNavigator oNodeSigValue = oNodeSig.SelectSingleNode(".//*[local-name(.)='signatureValue']");
XPathNavigator oNodeObj = oNodeSig.SelectSingleNode(".//*[local-name(.)='Object']");
//Clone the node
XPathNavigator oNode = oNodeObj.Clone();
//Move to the parent and append the cloned node
//Set the text value of the new node
oNode.InnerXml = "Example test data";
//Sign the data
e.SignatureWizard = false;
If you are building a solution where off-line mode is a requirement, you will need to design the solution with this in mind. For instance, if you have data connections that are queried on load of the form and you are passing parameters before querying that data source, this will fail when in off-line mode. To incorporate off-line mode functionality you need to programmatically check the “MachineOnlineState” and based on the results, take the appropriate action. In the following example, the MachineOnlineState is checked in the Loading event and a Boolean field is set to the result.
public void FormEvents_Loading(object sender, LoadingEventArgs e)
XPathNavigator docXN = this.CreateNavigator();
if (Application.MachineOnlineState == MachineState.Online)
docXN.SelectSingleNode("/my:myFields/my:online", this.NamespaceManager).InnerXml = "true";
docXN.SelectSingleNode("/my:myFields/my:online", this.NamespaceManager).InnerXml = "false";
docXN = null;
Selecting the Programming Language
By default, an InfoPath form template uses Visual Basic as its programming language. However, if you prefer, you can choose to use C#. To set the programming language used in a specific form, click Form Options on the Tools menu in InfoPath design mode and then select the programming language in the Form template code language list in the Programming category as shown in Figure 174. After you have selected the default programming language and written some initial programming code, you will not be able to change the programming language used in a form because the Form code language list will be disabled. (If you need to change the programming language, click the Remove Code button to remove all code associated with the form.)
It is also possible to write code for an InfoPath form template using Jscript or VBScript, InfoPath 2003 Compatible .NET code or you can use Visual Studio with the InfoPath Toolkit for Visual Studio .NET. For more information on this topic, see the Visual Studio Integration section of this document.
Figure 174: Select a default programming language
NOTE: To change the programming language for all new forms, select Options from the Tools menu, choose the Design tab and set the Programming language when designing forms that run in InfoPath and the Programming language when designing for InfoPath and InfoPath Form Services options to the language of your choice.
Debugging Script in InfoPath Event Handlers
If you leave the default programming language as one of the .NET options, then debugging your code is basically the same as other development environments: set a breakpoint and start the project in Debug mode. However, if you have selected a script option as your programming language, debugging your code will be slightly different. You can set breakpoints in the script editor; however, these breakpoints will not cause script to stop in the Microsoft Script Editor (MSE) until it attaches to your form at run time.
To cause the MSE to attach to your form at run time, you must first cause a programmatic break. If you’re using JScript as your programming language, insert the statement
in your script before the first breakpoint you want to hit. If you’re using VBScript, the programmatic break statement is:
When the script encounters these programmatic breaks, it will break and ask you to select a script debugger. Select the script debugger of your choice from those installed on the system and debug your script just as you would in other environments.
Figure 175: Select a Debugger
Form merging refers to the process of taking data from multiple forms and merging it into a new form, when all of the forms are based on the same form template. An example of this might be a manager who wants to take sections of the Task status reports of his employees and merge them into a Project status report for his director. Form merging can include all or only parts of the data contained in each form’s underlying XML document. It can also be used to replace or remove existing elements of the destination form, or to merge the attributes of two similar elements in the source and destination forms. To use form merging to combine the data in multiple forms, open an InfoPath form that has form merging enabled and click Merge Forms on the File menu. Pick the form from which you want to merge data, and click Merge.
Figure 157 Merge Forms
How Merging Forms Works
When you click the Merge button in the Merge Forms dialog box, InfoPath attempts to pull data from the source XML file based on its schema and incorporate that data into the destination form.
It does this by first comparing the name of the form template the source form is based on with the name attribute of each <xsf:importSource> element in the template’s form definition file. If it finds a match, the source XML file is validated against the schema specified in the schema attribute of the <xsf:importSource> element. If it is valid, the XSL transform specified in the transform attribute of the <xsf:importSource> element is applied and the resulting XML document is merged.
If no match is found with the name attributes, InfoPath tries to validate the source XML file against the schema specified in the schema attribute of each <xsf:importSource> element in the template’s form definition file. If it finds a match, the XSL transform specified in the transform attribute of the <xsf:importSource> element is applied and the resulting XML document is merged.
If the source document doesn't match the schema in any of the <xsf:importSource> elements in the template’s form definition file, the source XML document is compared against the destination XML document's schema. If the source XML document is valid against the destination schema, no transform is applied and the XML document is merged.
If none of these checks succeeds, InfoPath displays an error message. If multiple forms are being merged together, InfoPath can continue merging the remaining forms, or you can choose to stop the merge process.
Figure 158 Failed to Merge Form
Merging from XML Location Paths
InfoPath uses a two-pass process to merge forms. First, InfoPath treats the transformed source XML document as if it is similar to the destination XML document. This is the method used by the default form merge functionality. In this scenario, location paths of elements in the transformed source XML document are compared with location paths of elements in the destination XML document. For those elements whose location paths in the source and destination XML documents match, InfoPath uses the following rules to merge the elements:
If the maxOccurs attribute of the destination element is 'unbounded', the source element and all of its descendents are inserted after the destination element.
If the maxOccurs attribute of the destination element is '1', the attributes of the source element are added to the existing attributes of the destination element.
If the maxOccurs attribute of the destination element is some number greater than 1, the source element is ignored.
Merging from InfoPath Aggregation Instructions
In the second pass, InfoPath treats the transformed source XML document as if it is a list of aggregation instructions. It searches the source XML document nodes for attributes from the http://schemas.microsoft.com/office/InfoPath/2003/aggregation and http://schemas.microsoft.com/office/infopath/2003/aggregation-target namespaces. These attributes serve as aggregation actions specifying how each node should be merged with the destination XML document. The attributes are described below.
The agg:action attribute insert instructs InfoPath to insert the source element as a child of the destination element. The children of the source element are included in the insert. The select attribute is used to specify the location path of the destination element. The order attribute is used to specify whether the source elements are inserted before existing destination elements or after. The default value if the order attribute is not present is after.
agg:action="insert" agg:order="before">Some Value</my:field1>
The agg:action attribute replace instructs InfoPath to replace each of the destination elements referred to by the select attribute with the source element.
If the agg:action attribute mergeAttributes is found, the attributes of the source element are merged with the attributes of each of the destination elements referred to by the select attribute.
agg:action="mergeAttributes" my:myAttribute="Some Value"/>
If the agg:action attribute delete is found, each of the destination elements referred to by the select attribute are deleted from the destination document.
The target:get-documentElement function provides access to the Document Object Model of the destination document. It can be used to change the behavior of the merge operation based on the current contents of the destination document.
<xsl:variable name="target" select="target:get-documentElement()" />
<pss:Customer agg:action="insert" agg:select="/pss:MergeForms" />
A note on the “select” attribute
If the element has an agg:action attribute without a select attribute, the agg:action attribute is processed as if the select attribute were equal to the current location path.
Default Form Merge Functionality
InfoPath supports most form merging automatically. By default, InfoPath merges repeating groups and elements, along with their child elements and attributes, from forms that were created from the same form template; non-repeating groups and elements are not merged. InfoPath provides this functionality automatically. All that’s necessary to enable it is to select the Enable form merging check box in the Advanced category of the Form Options dialog box.
Figure 159 Enable form merging in the Form Options dialog box
Custom merging via the UI
Each node in the data source has a merge action associated with it. This action defines how data from the source form and target form is combined.
You can modify the default merge behavior, to accommodate most merge scenarios, through the User Interface (UI). Right-click in the repeating node in the Data Source Task Pane, select Properties, choose the Rules and Merge tab and click the Merge Settings button.
For Repeating Groups, you can customize how groups are merged, what action to take on blank groups and whether to combine groups with the same field value. In addition, you can customize how those groups are merged within the repeating element and whether to include blank groups.
Figure 160 Customize merge settings for Repeating Groups
For Non-Repeating Groups there are only two merge actions available: Preserve the contents of the group in the target form and Combine the contents of the groups in the source and target forms. If you choose the option to “Combine” then the merge action of each field and group within this group determine how the data is ultimately merged.
Figure 161 Custom merge settings for Non-Repeating Groups
The default behavior for Repeating Fields is to insert the fields from the source forms into the target forms. With this option you can also customize the insert order, whether to include blank fields and if a prefix should be added to the merged data.
Figure 162 Custom merge settings for Repeating fields
The default behavior for Non-Repeating Fields is to preserve the value in the target form; however, there may be instances where you want to concatenate the values from the merged forms. In these cases, you can also specify how each item is separated as well as if a prefix should be appended to the text.
Figure 163 Custom merge settings for Non-Repeating fields
The default behavior for Attribute fields is to Replace the field value in the target form with the field value from the source form. This behavior can be modified to either preserving the value in the target form or combining the values form the source and target forms. In addition, if you choose to combine the values you can also choose whether to include blank fields and if there is a separator between the combined data.
Figure 164 Customize merge settings for Attribute fields
Rich-Text Fields (Repeating and Non-Repeating)
When setting merge actions on Rich-Text fields, the default action is to Combine the values in the target form with the values from the source form. When choosing this option you can also specify if Blank fields are ignored, if the data should be separated by some character and if each item should be prefixed with a value.
Figure 165 Custom merge settings for Rich-Text fields
The controls that support merge functionality are:
Rich Text Box
Drop-Down List Box
Custom Form Merging via XSL Transform
In many cases, InfoPath’s new form merging functionality is sufficient. However, there may be times when you need to create custom form merging functionality. For example, you may want to merge data from forms that were created from different form templates, or from XML data files that weren’t created in InfoPath. The steps required to enable custom form merging functionality are described in the following steps.
1. Select the Types of XML Source Documents from Which You Wish to Merge Data
In many cases, this step will already be complete. You probably already know what kinds of XML documents you wish to draw your data from. Collect a representative sample of each type of source document.
2. Derive the XML Schema for Each Type of XML Source Document
For an existing InfoPath form, this step is easily accomplished by exporting the XML Schema with the Save As Source Files command on the File menu. For XML documents that were not created in InfoPath, you can use a tool such as Visual Studio .NET to create a schema from the sample XML document, or you can create a sample form from the XML document in InfoPath, and then export the schema that InfoPath derives from the document structure.
3. Determine the Data You Want to Merge from Each Type of XML Source Document
This step will depend almost entirely on the requirements of both your source and destination forms. For some forms, you may want to copy all of the data from the source form. For others, you may only want one or two elements from the form’s underlying XML document. When determining what data you wish to merge, pay careful attention to both the source and destination documents to make sure the elements map logically between the two forms.
4. Create an XSL Transform for Each Type of XML Source Document
This step will consume most of the time you spend enabling form merging for your form. The purpose of the XSL transform is to transform the source XML document into a form that can be merged with the destination form. When designing your transform, decide whether you want to use merging from XML location paths, or merging from InfoPath aggregation instructions as described in the How Merging Forms Works section.
Probably the easiest way to create the XSL transform is to use Visual Studio .NET or a text editor such as WordPad or Notepad. Visual Studio .NET provides syntax coloring and a document outline. It also automatically provides closing tags for your XSL elements, which can help cut down on redundant typing and hard-to-find spelling errors.
Start with the Identity transform, which is simply an XSL transform that outputs the same XML file that is input:
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:apply-templates select="@* | node()" />
<xsl:template match="@* | node()">
Then add overriding template sections for the elements you wish to add special handling for. For example, this template changes a <src:Task> element into a <my:field1> element and adds replace aggregation attribute.
5. Put the XSL Transform Files and Schema Files in the Form Template
After you have derived schemas for each type of source document and created an XSL transform to convert each document type so that InfoPath can merge its data, add them to your forms resources. Click Resource Files on the Tools menu, click Add in the Resource Files dialog box, browse to your schema or XSL transform file, and click OK. Do this to for each schema file and XSL transform file you created.
Figure 166 Resource Manager
If the schemas you add use the targetNamespace attribute, you must add a property element to the form’s .xsf file so that InfoPath knows the namespace of the schema. To access this file, click Save As Source Files on the File menu. Select a location for the files and click OK. Then close the InfoPath form you've been designing.
Browse to the location you selected and find the file with an .xsf file extension. Usually, this file is called manifest.xsf. Open the file using Notepad, find the <xsf:file> element that corresponds to your schema, and add a “namespace” property element to specify the targetNamespace:
<xsf:property name="fileType" type="string" value="Resource"></xsf:property>
<xsf:property name="namespace" type="string" value="urn:office-microsoft-com:InfoPath-designer-aggregation-IndStatusReport"></xsf:property>
6. Update the importParameters Section in the Form template .xsf File
The last step in preparing your form to support custom form merging is to update the importParameters section of the form's .xsf file. First, find the <xsf:importParameters> element in the form’s .xsf file. For each schema/XSL transform pair you've created for your form, add an <xsf:importSource> element to the <xsf:importParameters> element:
<xsf:importSource name="" schema="IndvTasks.xsd" transform="ImportTasks.xsl"></xsf:importSource>
The name attribute of the <xsf:importSource> element contains the form template’s name that may be found in a source XML document. Usually, you can leave this empty. The schema attribute contains the name of a schema file that you added to the form template CAB in the previous step. Finally, the transform attribute contains the name of the XSL transform that you want to use to convert forms that conform to the schema.
InfoPath design mode can create most of the view elements you’re likely to need. However, if you need a custom view element that InfoPath can’t create for you, you can manually modify the XSL transform that it uses to generate the view. To do so, extract the form into its component files and edit the transform in your preferred XML editor, such as Microsoft Visual Studio .NET or Microsoft Notepad.
Preserving Changes to a View
If you make changes to a view transform outside of InfoPath and then open the view in design mode and make changes, InfoPath will overwrite the changes you made manually. To keep InfoPath from overwriting the changes you make, you must place those changes in an <xsl:template> element in the transform and use the xd:preserve mode, as shown here:
<xsl:template match="my:field1" mode="xd:preserve">
The value of field1 is <xsl:value-of select="."/>
To include the template in the transformed file, use the <xsl:apply-templates> element with the same xd:preserve mode:
<xsl:apply-templates select="my:field1" mode="xd:preserve"/>
Conditionally displaying scroll bars
If the design of your view is such that, by default, scroll bars are not needed then you can enable the option: Show scroll bars when necessary so scroll bars only appear if needed to access all controls on the View. This is a per view setting and is on the General tab of the View Properties window.
Figure 167 Show scroll bars when necessary
If your business process requires that a View be read-only you can set this property at design time on a per view basis. This eliminates the need to set this property on a per control basis using Conditional Formatting.
NOTE: This property cannot be set at runtime. If a business process requires that when a certain condition is met the data must be read only, then you can use Rules to switch to a read only view when the specific condition has been met.
Figure 168 Read-only property
Bound fields in header and footer
The feature set for header and footer information has been extended with the ability to include bound fields from the form. This option is set on a per form basis and can include most field data; however, if a base64 encoded field is selected the encoded data will be displayed in the header/footer.
After selecting the view, click the View Properties button and select the Print Settings tab. Click either the Header or Footer button and from the Insert Auto Text drop-down box, select: Field.
Figure 169 Select a bound field
This will launch the Select a Field or Group window to select the appropriate field data to display in the Header or Footer.
Figure 170 Select the field to insert in the header or footer
Extending the InfoPath Control Set with Custom ActiveX Controls and Template Parts
InfoPath provides a rich and complete set of generic built-in controls, but there are some cases where there is a need for a control that is specific to your form or to your organization. InfoPath provides functionality to let users extend the set of controls available. Form developers can leverage currently existing ActiveX controls and use them within InfoPath. Also, following a few prescribed steps, software developers can write their own ActiveX controls to be used in InfoPath.
Custom Control Bindings
InfoPath’s custom control support allows users to create controls for three different types of binding:
Simple data type (string, numbers, etc)
Controls that are written to bind to simple data types would allow a control to do custom processing on data before it gets put into the XML. The control can be designed to have UI that combines multiple simple controls (buttons, textboxes, checkboxes, etc…) to encapsulate them into one control. For example, multiple buttons can be combined with a textbox to make an in-document calculator control. Combining these all into one control will provide a simple way to re-use the same control in multiple forms.
InfoPath allows XML nodes to follow any schema. This allows form developers to work with industry standard XML Schemas. One example is a MathML control that could be written for InfoPath to save XML compliant with the MathML schema and display it in InfoPath form in a meaningful manner.
For greater flexibility, InfoPath custom controls can be bound to an IXMLDomNode and any MSXML operations can be performed directly on the XML tree.
The built-in controls in Microsoft Office InfoPath give an extraordinary range of functionality for users to fill out forms. However, it is possible that you might need functionality that is not provided by these controls. In this case, InfoPath provides you with the ability to add custom ActiveX Controls to a form template and bind them to fields in the XML data source of the form.
Adding custom ActiveX Controls
Custom ActiveX controls are displayed in Custom section of the Controls task pane.
Figure 171 Custom Controls category
To add a custom ActiveX Control to a form template, go to the Controls task pane and select Add or Remove Custom Controls.... This will display the Add or Remove Custom Controls dialog box.
Figure 172 Add or Remove Custom Controls dialog
Clicking the Add button opens the Add Custom Control Wizard dialog which allows the developer to choose adding either an ActiveX control or a Template part.
Figure 173 Choose the type of custom control
Clicking the Next button on the Add Custom Control Wizard dialog lists the ActiveX controls registered on the designer’s system.
Figure 174 Add Custom Control Wizard dialog
Select from the list that control which you want to use on the form. Then click the Next button. The Wizard will ask whether to include a .cab file containing the control. If the end-users all have the control on their systems you will not need a .cab file. Otherwise you will need to package the control in a .cab and include it with your form template
After adding the control, you must specify a property to bind to a field in the form’s data source. This allows the control to save its data in the form. Note that the data in the property must be valid XML data in order to persist correctly. InfoPath will perform no interpretation or validation of the data.
Figure 175 Specify a Binding Property
On the next page select an Enable or Disable property
Figure 197: Specify an Enable or Disable Property
On the last page of the Add Custom Control Wizard dialog, specify which XML data types the control can be bound to. InfoPath will only allow the custom ActiveX Control to be bound to the specified types for data integrity. When you are satisfied with your selections, click the Finish button.
Figure 176 Specify the Data Types
Adding ActiveX Controls to Forms
An ActiveX control added to InfoPath will appear in the Insert controls list in the Controls task pane and through the shortcut menu in the Data Source task pane when selecting fields or groups with a matching data type. The control can also be dragged to the form, and then resized and otherwise modified like other InfoPath controls. If the control implements property pages, these will be shown along with InfoPath’s general property pages for ActiveX controls.
When an ActiveX control is required by a form and the control is not registered on the system, the behavior depends on the control settings within the form. If no CAB is included in the form template, InfoPath will not open the form. If the CAB is present, it must be installed. To install a CAB, the CAB must be signed, and the signature must be from a trusted publisher. If the publisher is not already trusted and a certificate is present, a dialog will prompt the user to trust the publisher. This behavior is distinct from Internet Explorer which allows installation of unsigned controls, or trusting of a control without trusting the publisher. InfoPath’s trust model matches that of macros and other signed code within Microsoft Office.
ActiveX controls will not be installed by or run in Forms with Restricted security.
Writing ActiveX Controls for InfoPath
In addition to using existing custom ActiveX Controls in InfoPath, you can write your own controls as well. Controls used in InfoPath should support the following list of COM interfaces:
IDispatch – for access to properties via late binding
IPersistPropertyBag – for property persistence
IPersistStreamInit – to save design-time properties
IPropertyPage – for design-time property pages
IObjectSafety – controls must be safe for initialization and safe for scripting
IPropertyNotifySink – so InfoPath can observe property changes
IViewObject – so control can render for down-level, e.g. email, export to web
IOleObject – communicates with host
IOleInPlaceObject – control can be in-place activated
In order for InfoPath to update properties in the DOM at the time they change in the control, the control should implement connection points (IConnectionPointContainer, IEnumConnectionPoints, IConnectionPoint, IEnumConnections) and fire the OnChanged() event with the DISPID of the changed property to notify InfoPath, which will advise on the connection point for the bound property. Firing this event will cause InfoPath to update the bound node with the updated value of the property. Controls that do not fire this event will have their bound nodes updated only at instantiation, save, view change, and other form lifetime events during which node properties must be refreshed.
Additionally, InfoPath defines two COM interfaces: IInfoPathControl and IInfoPathControlSite. The type library is present in infopath.exe.
IInfoPathControl defines an Enabled method and Init and Uninit methods. Init will be called when InfoPath is attaching the control to the view. It is passed the IInfoPathControlSite object which has two properties – Node (the XML DOM node to which the control is bound) and XDocument, a link into the full InfoPath object model. Uninit will be called when the control is about to be detached from the view and destroyed. Note that because InfoPath forms make use of XSL transforms to represent views, any changes in the data (or explicit calls to the OM) can cause AutoUpdates to occur, which destroy and recreate the view. This means that ActiveX controls are likely to be created and destroyed much more often within a given session than controls in VB forms or Web forms. ActiveX controls which need to preserve state independent of the bound data (e.g. scroll position) should use the XDocument.SetNamedNodeProperty to persist this information and restore it using XDocument.GetNamedNodeProperty during the Init call.
Due to the security requirements for InfoPath forms, ActiveX controls must either have categories defined in the registry or implement IObjectSafety and support “safe for initialization with unsafe data” and “safe for scripting”. Controls that do not meet these requirements cannot be added to the design environment and will not be allowed to run in edit mode.
Deploying ActiveX Controls to Developers
After exiting the Wizard, InfoPath writes out a file to %USERPROFILE%\Local Settings\Application Data\Microsoft\InfoPath\Controls with a filename based on the GUID and the extension ICT (InfoPath Control Template). If a CAB was specified, it will be copied into this directory with the same name but with a CAB extension. If you are creating ActiveX controls for InfoPath and wish to distribute them (e.g. to other developers within your organization, or to third parties) you can create an installer (e.g. MSI) which installs the control on the developer’s system and adds the .ICT and .CAB files to this folder directly. This will eliminate the need for developers to step through the wizard manually. The .ICT and .CAB files are not otherwise registered on the system, so “xcopy deployment” is supported.
If two or more developers are collaborating on developing forms which use ActiveX controls, all developers should have the controls added to their InfoPath design environment or they will not be able to modify the properties of the controls from within InfoPath.
Template Parts allow form designers to create XML “chunks” that encapsulate formatting, data source and XML editing behavior, and reuse that consistent look and behavior across multiple forms. Template parts can be used just like a control.
Inserting a Template Part on the form, once it has been added as a custom control, is the same as the normal insertion of a control. Each control that makes up the solution will have its own standard control experience. This independence means that inserting a Template Part multiple times results in multiple different groups of view, controls and data source.
A Template Part is composed of a View containing the controls, a schema fragment and XSF entries. This allows the user to insert an area that contains formatting and layout.
Creating a Template Part
Creating a Template Part is basically the same as creating a new InfoPath template. Launch InfoPath and on the Getting Started screen choose Design a Form Template. On the Design a Form screen select Template Part, choose whether to start with a Blank data source or one from a pre-existing XML or Schema file and click OK.
Figure 177 Design a new Template Part
Upon clicking OK InfoPath opens to a blank form where you can add the appropriate controls, formatting, data connections, etc. for designing the Template Part.
Once the design is complete, the Template Part can be saved locally or to a shared location (network share or SharePoint) to allow it to be accessed by other developers for use in their InfoPath templates.
Adding a Template Part to an InfoPath template
Template Parts are displayed in the Custom section of the Controls task pane just like ActiveX controls.
To add a Template Part to a form template, go to the Controls task pane and select Add or Remove Custom Controls.... This will display the Add or Remove Custom Controls dialog box.
Figure 178 Add or Remove Custom Controls dialog
Clicking the Add button opens the Add Custom Control Wizard dialog which allows selection of either an ActiveX control or a Template part.
Figure 179 Choose the type of custom control
Clicking the Next button on the Add Custom Control Wizard dialog allows the developer to browse for a Template Part.
Figure 180 Browse to select a Template Part
Once a Template Part has been selected, click Finish and then Close to close the Add Custom Control Wizard. If there are no additional controls to be added, click OK.
The Custom section of the Controls Task Pane now displays the Template Part that was added. Either drag and drop that control to the form or use the mouse to set the insertion point where the control is to be added and click on the control to add it at that location.
Updating a Template Part
Updating a Template Part is as easy as opening that Template Part in InfoPath and making the necessary changes. To incorporate the updated Template Part into an InfoPath form that contains a previous version of this Template Part, re-add the Template Part using the same steps noted above. However, if the Template Parts are stored in a SharePoint document library or in a shared network location then each time an InfoPath template that contains any of these Template Parts is opened in Design View it will automatically check for an updated Template Part and reflect that information in the Design Checker Task Pane.
In addition, new Template Parts added to the shared location will automatically appear in the Custom Controls section without having to go through the process of explicitly adding the control.
** NOTE: In order for the “auto update” functionality to work, the following registry key must also be set:
Create a string value called “IPCustomControlsFolder” under this key
Set the value to either the shared network or SharePoint location
Document Information Panels
A document information panel is a form that is displayed within the client application, and which contains fields for the document metadata. Document information panels enable users to enter important metadata about a file anytime they want, without having to leave the Microsoft Office system client application and are designed to enable users to specify all the properties on a document at once, in one place, at any point when they are working with that document. Document Information Panel template designers can design a custom InfoPath Form Template (XSN) through which the user will enter and edit data.
For files stored in SharePoint document libraries, the document information is actually the columns of the content type assigned to that file. The document information panel displays a field for each content type property, or column, the user can edit.
Users can edit document column values either at the document library level, or from within the Office System client application for the document. The metadata values are stored in the document itself, as well as in SharePoint. If the user updates the document metadata in the document, the new column values are promoted into SharePoint when the document is saved back to the document library. In the same way, if the user updates the content type column values in the SharePoint user interface, the new values are demoted into the document itself.
Document information panels are available in Word, PowerPoint, and Excel. Because document information panels are for documents, you can create custom panels only for content types that inherit from the Document content type. For example, you cannot create a custom document information panel based on a list schema.
You can create one custom document panel per content type, although that panel, like any other InfoPath form, can have multiple views. Document information metadata is stored within the document in a Microsoft Office Open XML Format part in a folder named docProps.
You can create custom document information panels in two ways:
Starting from the SharePoint user interface
Starting from the InfoPath application
When starting from the SharePoint user interface, you can choose the content type for which you want to create a custom document information panel. SharePoint launches InfoPath, and supplies the content type schema as the primary data source, as well as the automatically generated form as a starting point. When finished with the form, you can publish it directly to the content type or to some other location.
Note: For you to publish the form to the content type, you must first enable multiple content types for the document library.
If starting from the InfoPath application, you can browse to the desired site or list and select the content type for which you want to create a custom document information panel. InfoPath sets the selected content type as your primary data source, as well as the automatically generated form as a starting point. When finished with the form, you can publish it to the content type or to some other location.
Starting from SharePoint
When designing a Document Information Pane from SharePoint, navigate to your SharePoint document library and from the Settings menu choose Document Library Settings and then click on Advanced Settings. For the Allow management of content types Option select Yes and then click OK.
By enabling management of content types there is now a new Content Types section on the Document Library Settings page
Figure 181 Management of Content Types enabled
Click the Document Content Type and then click Document Information Panel Settings.
Figure 182 Document Information Panel Settings page
Click the Create a new custom template link to launch InfoPath and create a new Document Information Panel Form Template and in the Data Source Wizard in InfoPath – click Finish.
You now have a new InfoPath form but notice the only document property included in the form by default is the Title property. Select the Data Source Task Pane and drill down into the Properties node to see available fields.
Figure 183 Default Document Information Panel Template
NOTE: Notice the Title field is contained within a Horizontal Region control – this control will “flow” (horizontally) as the application hosting the panel is resized. If you want to be sure additional fields will flow as well, be sure to place them within a Horizontal Region control.
You can now choose to add other fields to the View and/or customize the format, add data connections, etc. to enhance the functionality of the Document Information Panel.
Figure 184 Creator field added to the Panel
Once you have the design as you need, save the InfoPath form locally and from the File menu choose Publish to publish the updated template back to the SharePoint document library. To insure this is displayed when a document is loaded, after the publishing process completes, enable the option Always show Document Information Panel on document open and initial save for this content type and click OK.
If you now click the New button, a new document will launch and should display the Document Information Panel with the modifications.
Starting from InfoPath
If you would prefer to start from InfoPath, launch InfoPath and select Design a Form Template from the Getting Started screen. Next, choose the XML or Schema option and click OK. In the Location box, enter the URL to your SharePoint document library (i.e.
http://servername/DocPanelTesthttp://servername/DocPanelTest) and click Next.
Figure 185 Document library URL
Select the Document Content Type, click Next and then click Finish.
Figure 186 Available content types
At this point, the steps to customize the template are the same as the Starting from SharePoint steps noted above.
Publishing Custom Document Information Panels
As with any InfoPath form, the location to which you publish your custom document information panel, and the security level with which you publish it, have important ramifications.
You can choose to publish the custom document information panel either directly to the content type resource folder or to a separate location.
Publishing directly to the content type resource folder guarantees that the form is published to the SharePoint Server computer on which the content type, and the documents it has been assigned to, also reside. The form is published to the same folder as the rest of the resource files for this content type.
Publishing to a separate location enables you to store all your forms in a central location, for example, in a forms library. This scenario enables you to restrict who has access to working on those forms. In addition, it enables developers who may not have access to the SharePoint site to work on the forms for that site.
Custom document information panels can have only Full Trust or Domain security levels. If you specify Full Trust, you need to digitally sign the InfoPath form template to deploy it to the content type resource file or other shared location. Otherwise, you must deploy the template as an installed registered template.
Because of security considerations, it is recommended to publish the XSN for your custom form to the same domain as the documents for which you want to use it. Otherwise, the custom form opens in Restricted mode, and the any data connections will not work. Saving the form locally will also cause any form that is not fully trusted to open in Restricted mode.
If you do save your custom form to a different domain, there are two options for making sure the data connections function properly:
Add the domain on which you saved the form to your list of fully trusted sites.
Deploy the form as a Microsoft Windows Installer file to install either a fully trusted form or a fully trusted and signed form.
Information Rights Management
Information Rights Management (IRM) allows individuals and administrators to specify access permissions to documents, workbooks, and presentations. This helps prevent sensitive information from being printed, forwarded, or copied by unauthorized people. After permission for a file has been restricted by using IRM, the access and usage restrictions are enforced no matter where the information is, because the permission to a file is stored in the document file itself.
IRM helps to do the following:
Prevent an authorized recipient of restricted content from forwarding, copying, modifying, printing, faxing, or pasting the content for unauthorized use
Prevent restricted content from being copied by using the Print Screen feature in Microsoft Windows
Restrict content wherever it is sent
Support file expiration so that content in documents can no longer be viewed after a specified period of time
Enforce corporate policies that govern the use and dissemination of content within the company
IRM can't prevent the following:
Content from being erased, stolen, or captured and transmitted by malicious programs such as Trojan horses, keystroke loggers, and certain types of spyware
Content from being lost or corrupted because of the actions of computer viruses
Restricted content from being hand-copied or retyped from a display on a recipient's screen
A recipient from taking a digital photograph of the restricted content displayed on a screen
Restricted content from being copied by using third-party screen-capture programs
To use IRM in InfoPath, the minimum required software is Windows Rights Management Services (RMS) Client Service Pack 1 (SP1).
There are two types of Information Rights Management (IRM) settings available in InfoPath, one for protecting access to InfoPath form template, and one for controlling access to and actions on form data contained in completed forms.
Protecting a form template
To protect a form template, select Manage Credentials on the File menu when designing a form template or click the Permission icon on the Toolbar.
Figure 187 Enabling IRM in Design View
When a form template has restrictions applied, everyone still has access to reading the form but only specific users would have access to opening the form in the Designer. In order for a user to open a template in Design View they will need to have at least Change permissions on the template.
Figure 188 Providing Change rights to a form template
If you have restricted permissions to a form template and not explicitly provided change permissions for a user, they will get an Access Denied error when attempting to open the form in Design View.
By enabling the Restrict permission to forms based on this form template option, the Change Permissions button is enabled. Clicking this button will allow you add additional user’s access to the form and enable additional permissions:
Allow users with “read” access to copy content
Access content programmatically
Figure 189 Permissions to form data
Protecting form data
When restricting permissions to data in a form, create a new form and then choose Permission on the File menu and select the appropriate permission.
Figure 190 Enabling IRM in Edit mode
After selecting Restrict Permission As (and choosing the appropriate user) or Do Not Distribute, enable Restrict permission to this form to add users with Read or Change permissions to the data.
Figure 191 Add permissions for users
By clicking the More Options button you can enable additional permissions:
Expiration date for the form (after this date, the form will no longer open)
Figure 192 Enable additional form permissions
IRM Object Model
There are two objects available to developers, the UserPermission object and the Permission object, that allow programmatic manipulation of IRM settings in forms.
The UserPermission object associates a set of permissions for the current form with a single user and an optional expiration date. Define a user and the permissions associated with that user with the properties of the UserPermission object, and then use the Add method of the Permission object to add and grant that user permissions on the current form. Use the Remove method of the UserPermission object to remove a user and the user's permissions. While some permission's granted through the user interface apply to all users, such as printing and expiration date, you can use the UserPermission object to assign them on a per-user basis with per-user expiration dates. The object model allows developers to enumerate permission settings in a form and to provide functionality that allows users to add permissions to the form without having to use the Form Permission task pane or the Permission dialog box.
The following sample code adds permissions for a specific user:
//Create a string variable to hold the user's name
string strUser = "firstname.lastname@example.org";
//Create a DateTime object to use as an expiration date on the form
System.DateTime expDate = new DateTime(2006, 12, 31);
//Apply the permissions
this.Permission.UserPermissions.Add(strUser, PermissionType.Read, expDate);
Opening IRM Protected forms
When a user opens an IRM protected form, if their credentials have not been cached, they will see the following message:
Figure 193 Connecting to IRM Server
After the user clicks OK to this message, they will see the following:
Figure 194 Verifying credentials
If the user does not have sufficient permissions to open the form, they will be presented with the following message:
Using IRM from Windows SharePoint Server
If Rights Management Server (RMS) has been configured on Windows SharePoint Server 2007 and an InfoPath document library has been configured to use IRM, permissions on the template and form data will be enforced by SharePoint based on the permissions provided to the user in SharePoint. Permissions to the form are enforced when the form is downloaded (opened) by the client.
When a SharePoint document library has been configured to use IRM, SharePoint controls that document. As such, if IRM has also been configured in the form, the permissions granted through SharePoint will override document level IRM.
IRM with Merged Forms
If permissions have been restricted on a form where merging has been enabled, rights on the source and target form are not modified after the merge. Instead they are used as the rule for enabling or disabling merge functionality. A user performing a merge on protected forms can only do so if they have at least change rights on both the source and target forms. If the user only has Read permissions on the target form, the Merge Forms menu option is unavailable. If the user has Change permissions on the target form but only Read permissions on the source form the Merge Forms menu option is available but when attempting to merge the source form the user will see an error.
Figure 195 Merge Forms error with Read permissions on the source form
Restricting permissions is only available on form templates compatible with the InfoPath 2007 client. Browser-compatible form templates do not support IRM. If you do not see Restrict Permission As on the File menu when designing a form template, check the compatibility setting.
InfoPath 2003 compatibility
If you attempt to restrict permissions on an InfoPath template that has been previously saved as an InfoPath 2003 Template, the following error will be displayed:
Figure 196 Restrict Permissions on InfoPath 2003 version template
If you restrict permissions on an InfoPath 2007 form template and attempt to save this as an InfoPath 2003 template, the save will fail and the Design Checker will show the error that restricting permissions is not supported in an InfoPath 2003 template.
Hosting InfoPath Forms
The InfoPath form editing environment can be hosted in custom Windows Form applications using the InfoPath Form Control and in custom web pages using the XmlFormView control.
Hosting InfoPath Forms in Windows Form Applications
The hostable editor feature of InfoPath allows developers to integrate the InfoPath form editing environment into custom applications. Developers writing traditional COM-based applications can use the InfoPathEditorObject object that is available by referencing IPEDITOR.DLL, and developers writing Microsoft .NET–based applications can use the Microsoft.Office.InfoPath.FormControl assembly, which provides managed types based on the COM interface.
Adding the Form Control and loading an InfoPath form
To load an InfoPath form in a Windows Form using the Form Control, you first need to add the Form Control to the Visual Studio Toolbox. To do this, right-click on the Toolbox and select Choose Items. Select FormControl on the .NET Framework Components tab, with the corresponding namespace of Microsoft.Office.InfoPath and click OK.
Figure 197 Add Form Control to the Toolbox
Once the control is on the Toolbox, adding it to your application is like adding any other control. Drag the control to your Windows form and then place and resize the control to accommodate the expected size of the InfoPath form template you intend to load into the control.
To programmatically load an InfoPath form into the Form Control you need to first add a “using” statement (or Imports statement in VB) for Microsoft.Office.InfoPath. Then in the Windows Forms’ loading event, you would use the NewFromFormTemplate method to load a new form based on an existing InfoPath XSN or the Open method to load an existing InfoPath XML file:
string myForm = @"C:\Template1.xsn"; //Modify the path to point to your template
//Open a form based on the solution
If the loaded InfoPath form has multiple views, you can easily switch views from buttons on the Windows form by using InfoPath’s object Model:
string myView2 = "vw2";
NOTE: You can access the underlying XML DOM document associated with the form by using the XmlForm class. The object model of the Form Control is based on the fully managed object model available in InfoPath 2007. Scripting languages, such as Microsoft JScript and VBScript —as well as Microsoft Visual Basic and C# languages using the SemiTrust interop object model for use with Microsoft Office InfoPath 2003 Service Pack 1—are not supported by the Form Control.
InfoPath 2007 contains a new data adapter for submitting the XML data generated by the form to the hosting environment. This new adapter, named SubmitToHostAdapter, has the corresponding manifest.xsf entry:
<xsf:submitToHostAdapter name="Submit" submitAllowed="yes"></xsf:submitToHostAdapter>
For information on implementing the SubmitToHostAdapter, see the Submitting Forms section. This allows you to handle the submit from the form, take custom actions and then still perform the submission by calling the Submit method of the XmlForm object.
InfoPath Features Not Available in the Hostable Editor
A number of InfoPath editor features will not work when hosting the Form Control in a custom application. The following items either do not function or are not provided automatically and require you to use an IOleCommandTarget to replicate the InfoPath form editing environment:
There are no menus or toolbars, but you can replicate this functionality by using custom menus and buttons along with an IOleCommandTarget
There is no ink entry mode
There are no custom or built-in task panes
The object model is limited to the XmlForm (XDocument) object and below
Forms protected with Information Rights Management (IRM) will not load
In order to use the Form Control in custom Windows applications, InfoPath is required to be installed on the computer used for developing the Windows application and on the computer used to run the compiled Windows application. If InfoPath 2007 is not installed on either computer, the Form Control will fail to load.
NOTE: The assemblies associated with the Form Control cannot be redistributed.
Hosting InfoPath Forms in custom web pages
Microsoft Office InfoPath Forms Services renders the XmlFormView ASP.NET control in a custom Web page. Browser-enabled forms are fully functional equivalents of forms designed in InfoPath, but they do not require the InfoPath client product to be installed on the computer using the form. InfoPath Forms Services must be enabled on the server, as part of either SharePoint or Microsoft Office Forms Server 2007, in order for InfoPath forms to be rendered in the browser. The XmlFormView control is only available on servers running InfoPath Forms Services.
Opening the SharePoint Site and Creating a custom Web Page
To create a custom ASPX page that hosts the XmlFormView control, launch Visual Studio and open the default web site for your SharePoint site.
Figure 198 Open the default SharePoint site
Then right-click the path of the Web site in Solution Explorer, choose New Folder and provide a name for this folder (i.e.CustomPage). Next you need to add a new ASPX page to the folder - right-click the new folder, choose Add New Item and from the Visual Studio installed templates list select Web Form. Provide a name for the new Web form, such as "MyCustomPage", select the Language and then click Add.
Setting Page Properties and Adding the XmlFormView Control
All custom Web pages that include the XmlFormView control require the page to have session state enabled and other default options either removed or modified.
In the Properties window for the new Web form, select DOCUMENT and set the EnableSessionState property to True. Next click the Source button in the lower-left corner to view the page in source mode and remove the default Doctype declaration tag (this tag begins with <!DOCTYPE html PUBLIC). We then need to modify the Form tag to contain the following “enctype” attribute:
Note: The encoding type (enctype) attribute is necessary only if you intend to use the File Attachment control in a form loaded into the XmlFormView control. If this attribute is not set properly, the File Attachment control will appear to function but will not upload a file to the server running InfoPath Forms Services.
The next step is to add the XmlFormView control to the ASPX page. Like the Form Control for Windows Forms projects, you will need to add the XmlFormView control to the Toolbox. Right click on a Tab of the Toolbox and select Choose Items. In the list of .NET Framework Components, enable the check box for the XmlFormView control. (If the XmlFormView control is not in the list, browse to Microsoft.Office.InfoPath.Server.dll – generally in C:\Program Files\Microsoft Office Servers\12.0\Bin)
Once the control is on the Toolbox, adding it to your ASPX page is the same as adding any other control: simply drag the XmlFormView control to the new page.
Configuring SharePoint and Resetting IIS
Once the control is added, there are options for the SharePoint site that need to be set and IIS will need to be reset in order for SharePoint to recognize the changes.
From the Web Site menu in Visual Studio select Start Options and in the Server section, select Use custom server. In the Base URL box, type
http://ServerNamehttp://ServerName (where ServerName is the name of your server) and click OK. Reset IIS by selecting Run from the Start button, type iisreset and press Enter.
Load web-enabled InfoPath Form Templates in the Control
In order to load an InfoPath file in the XmlFormView control, the form template must be published to SharePoint, it needs to be browser-compatible and reside in the same site collection as the custom web form.
With the XmlFormView control selected, modify the XsnLocation property of the XmlFormView control (in the Properties window) to point to a form template published on the server (i.e.
At this point, the custom web page could be launched in the browser and the XmlFormView control should displayed the specified form.
Coding with the XmlFormView Control
Various methods of controlling the behavior of the XmlFormView control are available to developers, such as changing the editing state, controlling whether the header and footer toolbars are visible, and controlling where the completed form is saved. These options can be controlled declaratively by setting properties in the Visual Studio user interface (UI), or programmatically.
The developer may also want to pass values from the Web page to the XmlFormView control or pass values from the XmlFormView control to the Web page.
Getting a Value from the Form to the Web Page
In order for code in the page to set the value of a field in the InfoPath form, it must be within an appropriate event handler. If the code is in an event of the XmlFormView control, such as OnSubmitToHost, then the data of the form can be accessed or modified directly. However, if the code is in an event handler of another control on the page, such as the OnClick handler of a button, then the code must call the DataBind method of the XmlFormView control before accessing the data of the form.
As an example of getting values form the InfoPath form to the web page, add the OnSubmitToHost event handler in the XmlFormView control tag:
<cc1:XmlFormView ID="XmlFormView1" runat="server" Height="250px" Width="100%" xsnLocation=
To be able to use Xml and XPath expressions and properties in your code, you will need to add the following “using” statements to the page:
Then it is a simple matter of adding the code for the OnSubmitToHost event handler:
protected void OnSubmitToHost(object sender, Microsoft.Office.InfoPath.Server.Controls.SubmitToHostEventArgs e)
XPathNavigator xNavMain = XmlFormView1.XmlForm.MainDataSource.CreateNavigator();
XmlNamespaceManager xNameSpace = XmlFormView1.XmlForm.NamespaceManager;
XPathNavigator fTextBox1 = xNavMain.SelectSingleNode("my:myFields/my:field1", xNameSpace);
TextBox1.Text = fTextBox1.Value;
To enable functionality of getting values from the web page to the InfoPath form, we can use the click event of a button on the web page.
protected void Button1_Click(object sender, EventArgs e)
XPathNavigator xNavMain = XmlFormView1.XmlForm.MainDataSource.CreateNavigator();
XmlNamespaceManager xNameSpace = XmlFormView1.XmlForm.NamespaceManager;
XPathNavigator fTextBox1 = xNavMain.SelectSingleNode("my:myFields/my:field1", xNameSpace);
fTextBox1.SetValue("Setting text from the form!");
This code uses System.Xml objects and XPATH expressions to drill into the XML of the loaded form.
There are a few things to be aware of when using the XmlFormView control in a custom Web page:
Only one XmlFormView control can be added per Web form (ASPX page)
For security reasons, the XsnLocation and the XmlLocation properties of the XmlFormView control must correspond to the same site collection as the custom page
InfoPath Forms Services, either as part of SharePoint or Microsoft Office Forms Server 2007, is required in order to render the form inside the XmlFormView the name of your server) and click OK. Reset IIS by selecting Run from the Start button, type iisreset and press Enter.
InfoPath Forms Serv