InfoPath 2007

Designing Form Templates With The New Features Of InfoPath

Scott Roberts and Hagen Green

This article is based on a prerelease version of the 2007 Microsoft Office system. All information herein is subject to change.

Contents

InfoPath Forms Services
Design Once
Template Parts
Document Information Panel
Hosting the InfoPath Form Control
Importing and Exporting Forms
Managed Object Model
Visual Studio Integration

InfoPath 2007 is an XML forms designer and editor package in the 2007 Microsoft® Office system. Now in its third iteration (if you include InfoPath® 2003 Service Pack 1), InfoPath has matured into a fully featured and integrated member of the Office family. In this article, we give you a sneak peek at some of its highlights and new features.

InfoPath 2007 includes a new Design a Form dialog (see Figure 1) that simplifies the process of designing form templates. You can also build Template Parts (reusable components you can insert into multiple form templates) as well as browser-enable your form templates and Template Parts. Browser-enabled forms are designed in InfoPath and can be filled out either in InfoPath or in a Web browser. Browser-based forms are hosted using InfoPath Forms Services from Microsoft Office SharePoint® Server 2007.

Figure 1** The Design a Form Dialog **

You'll find a number of new controls in InfoPath 2007, such as the Combo Box and Multiple-Selection List Box, both of which function like their Windows® control counterparts. To accommodate multiple selections, the Multiple-Selection List Box control binds to a repeating field in the data source and every selection adds another item to the repetition. As with the Combo Box, users can enter custom values into the Multiple-Selection List Box; this is configurable on the control during the design. Other new controls include Horizontal Repeating Table and Horizontal Region.

Integration with various Office applications is much improved. For example, InfoPath brings native form-filling capabilities directly to Outlook® 2007 and e-mail messages. Other Office system applications such as Word, Excel®, and PowerPoint® use InfoPath in their Document Information Panels, which contain a mini-form that lets users fill in metadata properties on the document.

InfoPath 2007 has many other enhancements: better form merging, exporting data, built-in form template importers for Word and Excel, the addition of Information Rights Management (IRM) to form templates, improvements for Tablet PC, and Visual Studio® 2005 integration. And there's InfoPath Forms Services, which lets your InfoPath forms reach out to anyone with or without InfoPath, at any time, on almost any device.

InfoPath Forms Services

InfoPath is great for building forms, but what about deployment? Not all of your customers will have access to the InfoPath client application—and they won't have to. InfoPath Forms Services, which is built on top of SharePoint Server 2007, uses SharePoint document libraries, content types, permissions, and administration to deliver an integrated forms-management package. Moreover, Forms Services is designed to extend the reach of your forms. Not only does it support Microsoft Internet Explorer® on Windows, it can also serve forms to Netscape and Firefox for UNIX and Windows, and even Firefox and Safari for the Macintosh, and it can render content for mobile devices such as Smartphones and PDAs.

To get a form template into InfoPath Forms Services for filling out in the browser, you design a form with the "Enable browser-compatible features only" setting checked from the Design a Form dialog shown in Figure 1. This is not an up-front requirement; the setting can actually be changed at any time during the design. While you're designing the form, notice that not all InfoPath features are available and some will be limited in their functionality in the Web browser. As we'll see, the few limitations that exist allow the same form to be used in InfoPath and Forms Services without any modifications. We call this "design once," and we'll review the concept in more detail in the next section.

Let's design the Status Report sample form under the Customize a Sample link in the Design a Form dialog shown in Figure 1. This form is already browser enabled, so all we need to do is publish it to a server running InfoPath Forms Services. To do so, click on the Publish Form Template link in the Design Tasks task pane. This brings up the Publishing Wizard, with various options for publishing forms. In this case, we're publishing to a SharePoint Server with InfoPath Forms Services. Subsequent wizard steps ask which server to use for publishing, whether you want to create a SharePoint document library or content type, and what form data (if any) to promote as columns in the library or content type. The last page offers a link to the library where we've published our browser-enabled form template. From there we can fill out our Status Report form.

Simply clicking the New button in the document library creates a new Status Report form. By default, the form will open in the InfoPath client application if it's available. That's because InfoPath is the preferred client for form filling (though there's a setting in the library to default to the browser). If InfoPath is not available, the form will render in the browser automatically. Figure 2 shows a filled-out form in InfoPath Forms Services. Notice that browser forms support rich text editing (as seen in the Summary field) with the Rich Text Box control. For comparison, Figure 3 shows the exact same Status Report filled out in the InfoPath client application.

Figure 3** Filling Out the Same Status Report Using InforPath **

Figure 2** Filling Out the Status Report Form in a Web Browser **

Design Once

Design once means you can create a form template that will work properly within both the InfoPath application and a Web browser. There's no need to decide ahead of time whether the form should target rich client or browser-based users. If you do choose to design a form specifically for the InfoPath client (and therefore not browser enabled), InfoPath exposes an extended set of features. Controls such as the Combo Box, User Roles, showing message boxes through a rule action, and the custom task pane are some of the extra features you'll see.

There are classes of features that don't work with Forms Services: unsupported and incompatible. If you include unsupported features (such as message boxes and custom task panes), you can still use the form template in Forms Services, but those features are nonfunctional. Incompatible features, in contrast, will fail when published to Forms Services.

How do we know which features are compatible and which are not? The Design Checker, shown in Figure 4, is a new task pane that communicates potential design problems to the developer. For this example, we designed a complex form that is not browser enabled. To make it compatible with Forms Services, we clicked on the Change Compatibility Settings link and modified the setting that enables the form to work in either a browser or in InfoPath. The Design Checker displays errors because our initial design included InfoPath client-only features, such as two Master/Detail controls that are incompatible with browser-enabled forms. When designing a browser-compatible form template, such features are not even available in the user interface. To begin fixing the errors, you simply click on the error to jump to the invalid control. If an error is not on a control, InfoPath gives instructions on how to proceed.

Figure 4** Design Checker Task Pane **

In addition to browser enabling the form, we also specified our server's name in the compatibility settings so we can enable the Verify on server option in the Design Checker. This option actually uses Forms Services to verify the integrity of the form template being designed. In this case, the server validation found an unsupported expression that InfoPath verification didn't catch. The Design Checker will also list browser optimizations when it detects form templates that may induce performance lags. Unlike for the InfoPath client application, performance optimization for InfoPath Forms Services is critical when tens of thousands of users could be filling out your forms simultaneously.

The Design Checker also serves other purposes. When you're using a form template importer like Word or Excel, the Design Checker will show importer warnings when, for example, unsupported features are removed. Additionally, the Design Checker reveals incompatibilities in form templates that must be backward-compatible with InfoPath 2003.

Template Parts

Custom controls were introduced with InfoPath 2003 Service Pack 1 (SP1), but support was limited to ActiveX® controls. Since ActiveX controls have been around for over 10 years, there are plenty to choose from. But only controls safe for scripting and initialization can be used in InfoPath form templates. And even those that are safe may not work correctly in InfoPath. If you don't find an existing ActiveX control that fits your needs, you can always create your own. This is time consuming, though, and requires in-depth knowledge of ActiveX technologies.

Luckily, InfoPath 2007 introduces Template Parts, which let you build custom components without code. As the name implies, Template Parts allow you to reuse parts of one form template in other form templates without having to rebuild each one from scratch. Let's say you have an XML schema that includes customer information such as name, address, phone number, and so on. You want to build a set of forms all based on the customer section of the schema without having to recreate the controls and schema that pertain to the customer information in each form template. With InfoPath 2007 you don't have to recreate all those controls.

When you design a form template in InfoPath 2007, you now have the option to create a Template Part instead of a form template, as the new Design a Form dialog in Figure 1 shows. You can create a blank Template Part just as you'd create a blank form template, or you can base your Template Part on an XML schema that includes customer information.

Once you specify Template Part in the Design a Form dialog, InfoPath opens in design mode. From here, the process of creating your Template Part is almost exactly the same as creating a form template. The only difference, as when creating a browser-enabled form template, is that not all features are available. Those features not supported in Template Parts simply aren't available in the user interface in design mode. For example, you can't add custom code to Template Parts so the Programming menu item is not available on the Tools menu.

Once you've created a Template Part based on the XML schema that contains customer information, you can insert controls that are bound to the customer information in the schema. And just as you normally would when designing a form template, you can add data validation, rules, calculated default values, and data connections. When you're finished, you save it as you normally would. This creates a file with an .xtp file name extension. (The .xtp file is similar to the .xsn file created when you save a form template.)

Before you can use your Template Part in form templates, you must install it into the InfoPath Controls task pane in design mode using the Add or Remove Custom Controls wizard. After the Template Part is installed, it is available in your Controls task pane just like any of the built-in InfoPath controls, and you can insert it into as many form templates as you wish.

As with the built-in InfoPath controls, when inserting a Template Part into a form template, the schema structure that pertains to your new control will be created automatically in the form template (if you have selected the Automatically create data source option in the Controls task pane) or you can choose to bind your control to an existing schema structure. Any of the features you added to your Template Part earlier, such as data validation or rules, will be automatically added to your form template. Template Parts not only enable you to create your own custom controls without writing code, they also give you a way to share parts of a form template across multiple form templates, thus saving much time and effort.

Document Information Panel

One of the main benefits of using InfoPath to fill out forms is its ease of use. As a form designer, you can quickly create form templates that provide a rich user experience and are based on common XML technologies. Users get the familiar experience of using an Office application along with the straightforward form-filling experience provided by InfoPath.

With InfoPath 2007 you can take advantage of this form-filling experience in your own applications. You might want to convert an existing application to use InfoPath for filling out forms without having to retrain your users. Or maybe you want to create a form repository tool that enables users to fill out forms and quickly find existing forms within the same interface. In either case, you probably don't want to create a new form editing tool from scratch.

Let's look at how InfoPath is hosted in other Office applications. The 2007 Office system introduces a new XML-based file format that is used in the core Office applications—Word, Excel, and PowerPoint. Since InfoPath can be used to edit XML-based forms, it makes sense that InfoPath can also be used to edit some of the XML in this new Office file format.

Word, Excel, and PowerPoint 2007 all include a new Document Information Panel, which is used to edit document properties in much the same way as you'd use a properties dialog in Office 2003. However, since the document properties are stored as XML, it makes more sense to use InfoPath for editing these properties. Figure 5 shows the standard Document Information Panel in Word 2007. As you may be able to tell, this is simply an InfoPath form hosted inside a Word document. At first, you may think this is no different from using the old properties dialog. But not only do you get certain InfoPath features such as data validation, you also have the ability to customize the user experience for editing document properties. Since the Document Information Panel is hosting InfoPath, you can now create your own form templates to edit the document property data.

Figure 5** Word Document Information Panel and InfoPath Form **

Hosting the InfoPath Form Control

Now let's talk about how you can put InfoPath to use in your own applications. Doing so can be quite simple. InfoPath 2007 packages its form-filling component as an ActiveX control you can host in your app. Support for hosting InfoPath in both managed and unmanaged code is provided so you can choose the technology you want to use to build your application. Obviously, hosting any ActiveX control in an unmanaged application is more complicated than in a managed app. However, if you already know how to implement an ActiveX control host application, doing so with the InfoPath ActiveX control is no different.

Let's take a brief look at how to host InfoPath in a managed Windows-based application using C#. (Any InfoPath-specific concepts we discuss can just as easily be applied to unmanaged applications and to other managed languages.)

After stepping through the New Project wizard in Visual Studio 2005 to create your Windows-based application in C#, you'll need to add the InfoPath form control to the Visual Studio toolbox before you can use it. To do so, click on Choose Toolbox Items from the Tools menu, click on the .NET Framework Components tab, and then locate the component named FormControl in the Microsoft.Office.InfoPath namespace. (In unmanaged code, the FormControl class is equivalent to the IInfoPathEditor interface.) Once the InfoPath form control is in your toolbox, you can add it to your Windows form just as you would with any other control.

If you build and run your application at this point, the InfoPath form control will be instantiated but it won't do anything useful. Most likely you'll want the InfoPath form control in your application to load a form. If you look at the FormControl object in the Object Browser in Visual Studio 2005, you'll see that the InfoPath form control provides a number of useful methods and properties. Probably the most important methods available are the ones that let you load a form into the InfoPath control—Open and NewFromFormTemplate.For the purposes of this simple example we'll use one of the two NewFromFormTemplate methods—the one that takes the URI of the InfoPath form template you want to load as a string parameter. For example, if you want to load a form template containing customer information, you could do so by adding the following code:

formControl1.NewFromFormTemplate(@"\\mysharelocation\customerInformation.xsn");

Alternatively, if you want to load an existing form, you could use the open method, like so:

formControl1.Open(@"\\mysharelocation\myForm.xml");

Note that the XML file you pass to the open method must be a valid InfoPath form.

The XmlForm property is equally useful. (In unmanaged code it is equivalent to the get_XDocument method on the IInfoPathEditor interface.) This property gives you access to the entire InfoPath object model for the form. Certain objects in the InfoPath object model, such as the Application and Window objects, aren't available when hosting the InfoPath control. These objects pertain to the InfoPath client application, so have no meaning when hosting the InfoPath form control.

The methods and properties available on the FormControl object give you a few ways to manage and interact with the hosted InfoPath form control. But this object obviously doesn't provide full control over the hosted form. For example, how do you make text bold or italic in the form? How do you insert a table into a RichText Box control? These and other features that are available in the InfoPath client application through the user interface aren't available through the FormControl object. However, you can access virtually all of these features from your own applications, using the IOleCommandTarget interface.

In unmanaged code, using IOleCommandTarget is straightforward. You simply obtain a pointer to the interface from the hosted control and then pass a command to the Exec method (Likewise, you can call the QueryStatus method to see if a command is currently supported.) In managed code, you must use COM interop to access the interface. To find a list of all the available commands simply look at the FormControlCommandIds.CommandIds static helper class in the Microsoft.Office.InfoPath namespace. (In the Object Browser in Visual Studio, the FormControlCommandIds.CommandIds is listed under the Microsoft.Office.InfoPath.FormControl namespace. There are literally hundreds of commands that enable you to control hosted forms from within your application.

With the support for hosting InfoPath in managed applications, you can create a simple hosting application in literally just a few minutes. You can also host the InfoPath Forms Services component. A form in the browser can be rendered by hosting the XmlFormView ASP.NET control in an .aspx page. (The XmlFormView class is defined by the Microsoft.Office.InfoPath.Server.dll assembly in the Controls namespace.) In fact, when you fill out a form in the Web browser that isn't hosted, you're really looking at a mostly empty .aspx page that hosts the XmlFormView control.

To use this control in your own ASP.NET page, your page must live on a SharePoint Server 2007 server that is running Forms Services. Then you can use Visual Studio 2005 to add the control to the Toolbox (as described earlier for the InfoPath Form Control) and insert it into the Visual Studio design surface of your ASP.NET Web site project. As you code against the XmlFormView control, you might notice that the entire InfoPath object model is available to the host page. This is a façade, though, because only a strict subset of the object model is actually allowed to be called by the hosted page. For example, the data source is accessible through the MainDataSource property, but accessing the form's Errors collection is restricted. An exception is thrown when calling any restricted properties and methods at run time.

Hosting a Web Form in the browser is another exciting prospect for your InfoPath forms. Not only can you reach out to users without InfoPath, you can also integrate the InfoPath form-filling experience into your own Web pages while maintaining the integrity of your Web site's appearance.

Importing and Exporting Forms

InfoPath 2007 provides more support for exporting data to other applications. InfoPath 2003 let you export forms to a Web page or to an Excel spreadsheet. InfoPath 2003 did allow you to export a form to an Excel spreadsheet but now there is more extensive support for exporting your data.

And InfoPath allows you to import forms as well. The framework for building form importers was available in InfoPath 2003 SP1, but only now does InfoPath ship with built-in importers. With InfoPath 2007, you can import forms from either Word or Excel. When you import a form, an InfoPath form template is created which you can then customize to meet your needs. You may be thinking that you can already transform a Word or Excel form into an InfoPath form by copying and pasting the form into InfoPath. However, importing has a huge advantage over copy and paste: the built-in importers will create controls and schema for you automatically. For example, suppose your Word form contains text, as shown in the following:

Enter your name: _________________________

In this case, users know they are supposed to enter their name in the underlined area of the document. InfoPath will detect this construct and create a Textbox control in the view. That Textbox control will be bound to a field element in the schema. The fact that the built-in InfoPath importers create controls and schema will certainly save you lots of time when you're migrating forms from Word and Excel to InfoPath.

InfoPath 2007 also provides tight integration with Outlook 2007. You can publish a form template in InfoPath 2007 to a list of e-mail recipients. This gives you a quick way to distribute a form template to accomplish simple tasks such as gathering survey data. When Outlook 2007 users receive the form, they can fill it out from within Outlook without having to open the InfoPath client application. Figure 6 shows an InfoPath e-mail form that will collect survey data.

Figure 6** InfoPath E-Mail Form **

Outlook 2007 supports creating InfoPath form folders to store submitted forms and includes rules for moving specific InfoPath forms to those folders. Using InfoPath form folders along with InfoPath property promotion, the data from the submitted forms are visible as columns in each form folder. Therefore, you can quickly see the data contained within the submitted forms without having to open each individual form. Since these folders are typical Outlook folders, you can sort and group information, which lets you make decisions in less time.

Managed Object Model

If you wrote managed code behind a form in InfoPath 2003 SP1, you're accustomed to hooking up events using attributed methods and the thisXDocument and thisApplication objects to access the bulk of the object model. In InfoPath 2007, the API is much improved. To hook up an event, simply use the .NET-style event assignment in the InternalStartup method of your form code class (this code and the associated event handler can also be auto-generated through the Tools | Programming menu flyout):

EventManager.FormEvents.Loading += new LoadingEventHandler(FormEvents_Loading);

There have been some name changes: the old OnLoad event is now named Loading, and all XML events have been renamed to Changing, Validating, and Changed. Also, the InfoPath 2007 data source is exposed in code as an XPathNavigator instead of MSXML's XML document and node interfaces. This change provides a performance-oriented cursor-based approach to working with the underlying form data. (To get the main data source navigator, use this.MainDataSource.CreateNavigator.)

Many objects that were grouped in thisXDocument are now inherited members, and some even sport updated names (such as the MainDataSource member). A few others include CurrentView, DataConnections, DataSources, Errors, and SignedDataBlocks. One of the more popular methods to use in form code was to display a dialog using:

thisXDocument.UI.Alert("message")

Now you'd use the System.Windows.Forms namespace's MessageBox class. By calling the static method Show off of the MessageBox class, you can show the same dialog as the old Alert method. Better yet, Show also has overrides to use message box captions, buttons, and even a custom icon.

Best of all, the InfoPath object model abides by the design-once philosophy we talked about earlier: the code you write behind your form can be used on both the client and server.

Visual Studio Integration

To help rapid development of sophisticated form templates, InfoPath takes advantage of the Visual Studio 2005 environment. Since Visual Studio is the platform of choice for Windows-based development, it is a smooth transition to InfoPath.

For InfoPath 2003, Microsoft Script Editor (MSE) was the included development environment. But its usefulness was limited to writing JScript® and VBScript code. Without Visual Studio .NET 2003 and the associated InfoPath Toolkit, you could not easily write managed code behind an InfoPath form. For InfoPath 2007, Visual Studio Tools for Applications supplements MSE as the environment for writing your managed form code. It will be familiar if you've used Visual Studio and it includes many of the core features you need: IntelliSense®, an object browser, and a full-featured debugger. Simply run the project in Visual Studio Tools for Applications and you'll be debugging your form in InfoPath's preview mode within seconds.

To meld the development of the form code with the designing of the form template, you can use Visual Studio 2005 Tools for the 2007 Microsoft Office system, which takes the InfoPath design mode and integrates it directly into the Visual Studio IDE. The full lifecycle of designing a new (or existing) form, inserting controls, modifying data sources, and sprinkling features such as conditional formatting, data validation, and rules all take place in Visual Studio. Previewing and actually filling out the form, however, are left to InfoPath. Designing a form with Visual Studio Tools for Office is shown in Figure 7.

Figure 7** Designing an InfoPath Form with Visual Studio Tools for Office **

Besides the integrated design environment, there are other benefits to using Visual Studio Tools for Office. They include being able to use multiple simultaneously visible task panes, the Visual Studio Find and Replace functionality, and taking advantage of plug-ins such as Visual SourceSafe for source code control when collaborating in a team setting.

The topics we've discussed are just a few of the highlights of InfoPath 2007. We hope this brief introduction will spark your interest and will prompt you to explore InfoPath 2007 further. If you are new to InfoPath or would like more detailed information about designing forms, see the InfoPath Web site at office.microsoft.com. Tune in to the InfoPath Team Blog at blogs.msdn.com/infopath for info from the product team.

Scott Roberts is a Senior Development Lead in the InfoPath group at Microsoft. Scott is the coauthor of the upcoming book Designing Forms for Microsoft Office InfoPath and Forms Services 2007 (Addison-Wesley). Scott is also the author of Programming Microsoft Internet Explorer 5 (Microsoft Press,1999) as well as many technical articles and publications.

Hagen Green is a Software Design Engineer in Test on the InfoPath team at Microsoft. Hagen has worked on InfoPath features such as the designer platform, XSL support, Web services and Data­Sets, and most recently on InfoPath Forms Services. He is the coauthor of the upcoming book Designing Forms for Microsoft Office InfoPath and Forms Services 2007 (Addison-Wesley). Scott and Hagen can be reached at DesigningIPForms@hotmail.com.