Windows Insider

Down the Winding InfoPath

Use Microsoft's least-understood Office tool to create XML-based forms.

I hate forms in Microsoft Word. I really do. You know what I'm talking about -- those nasty little grey boxes that make text hard to read, jump around when you hit the Tab key, and sometimes delete too much when you try to Backspace.

Not long ago I decided I'll never use Word 2003 forms again. So, when handed yet another project that needed them, I chose to look into Microsoft's least-understood Office tool: InfoPath 2003.

Offered as a stand-alone product or bundled with Office Professional Enterprise Edition, InfoPath is an XML-based forms design tool with tight constraints on how your form conforms to an established XML schema. Whether you submit your form to a database or save it as an XML file on a file share or SharePoint server, starting a project in InfoPath is a lot like Microsoft Access. Before you ever begin designing, you must understand the data you're collecting and how you want it stored. That being said, here are six quick tips I learned that'll come in handy as you create your first InfoPath project.

1. Create Your Data Source First
For simple forms that won't submit to a database, creating your XML schema is easy. As an example, open InfoPath and choose to design the sample Status Report form. You'll see that text boxes in the form map to fields in the Data Source. This is a key factor in forms design. Before you create any text or check boxes on your form, you must already have an existing entry in the data source where that box's data will be stored. In forms that don't attach to databases, you create new fields in the data source by selecting the folder group and then clicking the Add… button (see Figure 1).

All your information are belong to InfoPath.
[Click on image for larger view.]
Figure 1. The singleName text box in the form design maps to the singleName field in the form’s Data Source.

2. To Database or Not to Database
Where it gets harder is when you want to submit your forms to a database. InfoPath supports direct database connections only to SQL Server and Access databases, and won't allow you to submit your forms if the database has a many-to-one relationship between related tables. Forms that submit to a database seem more difficult because you can't directly add or remove fields in the data source from within InfoPath. Fields in your data source are completely constrained by the columns in your database. Need a new field in your form? Create a new column in your database and update the SQL query in your Data Connection.

If you're using SQL Server as the database for your form, consider linking the form to a SQL View rather than directly to a table. This makes it easier to manipulate the view if you need to make a change, as well as making it easier to apply security to your database.

3. Drop and Give Me 20!
Drop-down list boxes can be a little tricky. There are three ways you can populate a drop down list box:

  • Manual entry in the drop down's properties
  • Use a lookup table stored inside the form's code
  • Use a secondary lookup to a database

Of these, the lookup to the database is the most useful, and also the most complicated. To populate a drop-down list from a database table, you'll want to create a Secondary Connection to a lookup table in your database and populate the entries from that Secondary Connection.

What's not immediately obvious -- and annoying -- is InfoPath's inability to restrict that lookup to just a single instance of each entry in your secondary lookup. If you're seeing doubles in your drop down list box, you'll need to create an XPath filter expression that eliminates the duplicates. Do this with the following expression:

not(. = ../preceding-sibling::*/@<Column Name>)

4. Donning Your Input Mask
If you're used to Access, you're probably familiar with the friendly input mask feature that forces data into a pre- determined structure -- like when you want to force phone numbers be stored as (XXX) XXX-XXXX. InfoPath doesn't natively have that capability, but you can cheat it using Data Validation. Though InfoPath Data Validation won't pre- populate the field's mask characteristics, users will be forced to enter data in the correct format or the form will reject it.

You can do this by double-clicking on a text box in your form, selecting Data Validation…, and then Add…. In the Data Validation dialog box, select Does Not Match Pattern from the second drop-down box and Select a Pattern from the third. You'll be given a few example patterns, like our phone number example above, or you can create your own by using \d to represent any digit or \p{L} to represent any letter. Make sure to enter in an error message to alert users when an entry doesn't match the pattern.

Oops. Your bad.
[Click on image for larger view.]
Figure 2. Use InfoPath Data Validation to display an error when users enter data in an incorrect format.

Because InfoPath doesn't pre-populate the mask characteristics, you'll probably want to inform your users of the correct pattern for that text box. Do this by entering your pattern as a Placeholder on the Display tab of the text box properties, as shown in Figure 2.

5. Trust Me
While simple forms that lack VBScript- or Jscript-coded events don't require certificates, any form that interfaces with a computer's WMI (Windows Management Instrumentation interface) does. For example, if you want to store the Active Directory username of the person filling out the form to a field in your form, you can create an OnLoad event that does this with the following snippet of code:

Sub XDocument_OnLoad(eventObj)
 Set wscNet = CreateObject("WScript.Network")
 XDocument.DOM.selectSingleNode("/my:<group>/my:<field>").text = wscNet.UserName
End Sub

InfoPath's strict security model won't allow the form to interface with the local computer's WMI unless the form is considered Fully Trusted. To do this, you'll need to sign your form with a trusted code signing certificate:

  • If you don't already have one, build a Certificate Server and generate its root certificate.
  • Then, create a Group Policy that adds that certificate to the Trusted Root Certification Authorities container on your machines.
  • Create a code signing certificate with an exportable private key.
  • Finally, in the Design View of your form, select Tools | Form Options | Security, sign the form with your code signing certificate and set the security level to Full Trust.

Users will be prompted with a window requiring them to trust the certificate when they first attempt to load your signed form.

6. Feels Like the First Time
Sometimes, even a complete install of Office 2003 won't properly configure the client machine to make it easy for new users, who will get a dialog box asking them if they want to save the file or open it from its current location.

To eliminate the dialog box, you can use Group Policy to configure your machines to automatically open the form. Do this by creating a Group Policy startup script that calls regedit /s GPStartupScript.reg. Then, create a GPStartupScript.reg file with the following syntax:

Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\InfoPath.Solution.1]
@="Microsoft Office InfoPath Form Template"
"EditFlags"=dword:00010000
"BrowserFlags"=dword:00000008

Even with this startup script, you may still have some client requirements for your InfoPath forms to work. Make sure that all your clients have a recent version of both the .NET Framework and the Microsoft Data Access Components installed.

Diamond in the Rough
Although it's still a little rough around the edges and its GUI has some annoying quirks, InfoPath gets high marks as a useful tool for creating XML-based forms for both small business and the enterprise. Unfortunately, in trying to be everything for everyone, it ends up with a pretty hefty learning curve.

My advice: Start small. It's incredibly easy to build forms that don't integrate with SharePoint, SQL, Access or Web services. Once you're familiar with the basics of InfoPath, you can add a little scripting and a database back-end and never again experience the pain of Word's grey boxes.

About the Author

Greg Shields is Author Evangelist with PluralSight, and is a globally-recognized expert on systems management, virtualization, and cloud technologies. A multiple-year recipient of the Microsoft MVP, VMware vExpert, and Citrix CTP awards, Greg is a contributing editor for Redmond Magazine and Virtualization Review Magazine, and is a frequent speaker at IT conferences worldwide. Reach him on Twitter at @concentratedgreg.

Featured

comments powered by Disqus

Subscribe on YouTube