Microsoft InfoPath 2010
The official blog of the Microsoft InfoPath team

  • Microsoft InfoPath 2010

    MSDN WebCasts: InfoPath 2007

    In April, the InfoPath team will present three MSDN WebCasts introducing the new features available in InfoPath 2007. These three presentations will provide a high-level overview of InfoPath 2007. In the future, we will offer more detailed presentations that dive down into individual features of InfoPath 2007.
    We hope you will join us for the first three InfoPath 2007 presentations. Here is more information about the first three talks including the schedule.
    New Features in Office InfoPath 2007
    Time: Tuesday, April 11, 2006 12:00 PM – 1:00 PM (PST)
    Presenter: Gray Knowlton, SR. Product Manager - Office
    Description: This webcast presents an overview of the new features in Microsoft Office InfoPath 2007 and InfoPath Forms Services. Join us to learn how you can use InfoPath 2007 to automate and extend business processes by utilizing XML and integration standards to connect electronic forms to virtually any application or system.
    Developing, Deploying, and Hosting Rich Client and Browser Forms for Microsoft Office InfoPath 2007
    Time: Tuesday, April 18, 2006 12:00 PM – 1:00 PM (PST)
    Presenter: Kalpita Deobhakta, Program Manager - InfoPath
    Description: Were you aware that you can design Microsoft Office InfoPath 2007 forms for both the rich client and the browser in a single step? This webcast presents the design-once process for InfoPath 2007, and covers debugging, deployment, and improving the performance and scalability of forms. Find out how to host the InfoPath rich client in other applications, and how to tightly integrate InfoPath 2007 forms into Web pages. We also discuss best practices for using the hosted form control to build powerful but easy-to-use solutions.
    Developing InfoPath Forms for Office InfoPath 2007
    Time: Monday, April 24, 2006 10:00 AM – 11:00 AM (PST)
    Presenter: Nima Mirzad, Program Manager - InfoPath
    Description: This webcast presents an overview of Microsoft Office InfoPath 2007 programmability features including the managed object model, template parts, and provisions for third-party hosting. We also discuss techniques for using Microsoft Visual Studio 2005 Tools for Applications (VSTA) and Microsoft Visual Studio 2005 Tools for the Microsoft Office System (VSTO) to develop Office InfoPath 2007 forms.
    Scott Roberts
    Software Design Engineering Lead
    Microsoft Office InfoPath
  • Microsoft InfoPath 2010

    Working with VSTO 2008 Projects in InfoPath 2010


    The InfoPath team is busy working on the next version of Office.  While we’re offline, we’d like to take the opportunity to tackle some of the questions that we get asked frequently by InfoPath users. 


     Today I’ll talk about how to migrate your InfoPath projects from Visual Studio Tools for Office 2005 or Visual Studio Tools for Office 2008 (VSTO) into InfoPath 2010 with Visual Studio Tools for Applications (VSTA).

     The decision to remove the ability to include InfoPath projects in professional developer solutions has been a controversial one, but is consistent with our overall message about SharePoint development – Create InfoPath forms with as little code as possible, and put the bulk of your code into middle tier services and workflows.

     That said, we frequently hear from users who invested in VSTO projects and need to know how to move those projects forward with InfoPath 2010 and Visual Studio 2010.  Here’s how.

     This walkthrough will demonstrate how to migrate InfoPath code projects from Visual Studio Tools for Office (VSTO), and into Visual Studio Tools for Applications (VSTA).

     First, ensure that VSTA is installed

     VSTA is an IDE included with InfoPath 2007 and InfoPath 2010.  The VSTA node is included in InfoPath 2010 setup.  Launch Office setup, choose to customize the install, and set Visual Studio Tools for Applications to ‘Run from my computer’.


    Next, migrate your project

    After installing VSTA, make a backup copy of your VSTO 2008 project that you will now proceed to migrate.

     Let’s walk through the conversion process of a VSTO 2008 project named “Hardware Order Form”. This project includes:

    1.       Custom classes used to create database connections and run queries. See DBConnection.cs.

    2.       External XML that are linked to the InfoPath data source. See Items.xml.

    3.       InfoPath form code. See FormCode.cs

    4.       References to non-default NETFW assemblies. See System.Windows.Forms and System.Data.

     Here is a screenshot of the Visual Studio project explorer to give an idea of the project structure:

    To migrate this project to VSTA

    1.       Launch Windows Explorer, and navigate to the InfoPath “manifest.xsf” for your project. This file is included in the “InfoPath Form Template” directory of your Visual Studio 2008 project by default.

    2.       You’ll see a list of files that directly correspond to the “InfoPath Form Template” directory shown in the VS Solution Explorer screenshot above. For example:

    3.       Right click “manifest.xsf”, and choose Design from the context menu

    4.       InfoPath 2010 Designer will launch.

    5.       Click the Code Editor button in the InfoPath 2010 Developer tab, and the browse dialog will appear



    6.       Click the Browse button, and navigate to the csproj file in the backup copy of your project. Select the csproj file and click ‘Open’.


    7.       VSTA will launch, and your project will be successfully migrated into InfoPath 2010 and VSTA.

     You can now work from within InfoPath 2010 and VSTA to code, build, and publish your solution.

  • Microsoft InfoPath 2010

    Using Multiple Views in Customized List Forms


    Hi, my name is Laura Harrington, and I’m a program manager on the InfoPath team. In this short video demo, I will show how you can optimize the form filling experience for different tasks and users by creating multiple custom views in your customized SharePoint list forms.

    Get Microsoft Silverlight
  • Microsoft InfoPath 2010

    Digital Signatures: Layout Tricks


    Folks frequently ask whether it is possible to customize the InfoPath user interface around digital signatures. Some want to show the signature at the very bottom of the form; others want to show signatures side-by-side; others want to disable form submissions when the document wasn't digitally signed. In this article, we'll look at different ways you can tweak the form design to make it happen.

    Trick 1: Display signature at the bottom of the view

    InfoPath lets you show digital signature UI ("click here to sign this form") under a signable section; however, this section doesn't have to include any controls! This means that you can have your signable section with controls at the top of the form, some extra content in the middle, and then another section bound to the same nodes in the data source without any controls in it.

    Your design view would look like this:

    Note how the signableGroup here is multiply bound; the first section has the "allow users to digitally sign this section" checkbox unchecked:

    The second one has it checked, which makes the "click here to sign this form" show up; this is how the end result looks at edit-time:

    Trick 2: Disallow Submit if form was not signed

    InfoPath digital signatures are appended to form XML, just like form data. For example, in the form above, nodes under signature1 will store the digital signature when the user adds it:

    Using this fact, we can enforce business rules in our form: for example, what if we don't want to allow form submissions for cases when form is not signed? Let's go to Tools | Submit Options and create two rules:

    1) Show must-sign warning:

        - condition: signatures2 node is blank (this will evaluate to true when no signature was added)

        - action: show a dialog box message "you must sign the form before submitting it"

        - check "stop processing rules when this rule finishes"

    2) Submit to main data source:

        - condition: always applies (unless the first rule fired - we wouldn't get to this execution point then)

        - actions: submit to main data source + show dialog box message "submission was successful"

    Trick 3: Show signatures side-by-side

    Challenge: make a form that has signatures side-by-side at the bottom; additionally, person 3 should only be able to add their signature if previous signer (person 2) already signed the document.

    We already know how to make the signatures appear at the bottom of view (trick 1); we also know how to determine if a signature was added to the document (trick 2). Let's put all of these tricks together into one powerful solution:

    - Create 3 different signed data blocks, one for each person that will be signing the form. Second data block needs to signing a superset of data that the first one signed, etc.  Your data source task pane will look like this: 

    - Place empty sections bound to the items that you want to sign in the columns of that table.
    - Use containing conditionally-formatted sections to show the signing UI only when necessary.

    The resulting layout will look like this:

    I'm attaching a sample form template that has this trick implemented (works in InfoPath 2003 or 2007; save the XSN to your computer before opening it).

    Alex Weinstein
    Program Manager

  • Microsoft InfoPath 2010

    Designing browser-enabled forms for performance in InfoPath Forms Services (Part 4)


    Part 4 – Browser Rendering Issues

    Welcome to the fourth article in our series on optimizing the performance of InfoPath browser-enabled forms. In our previous articles we defined performance in terms of responsiveness, listed a number of conditions that cause postbacks, and looked at some of conditions that make postbacks more expensive, reducing the responsiveness and scalability of a form system. In this article we’ll examine some of the issues that affect form rendering performance in the browser. We’ll also take a quick look at using the Design Checker to monitor browser compatibility issues while designing a form template in the InfoPath Designer.

    Conditions that slow form rendering in the browser

    There a several conditions that can reduce form-rendering performance in the browser. The main effect of these conditions is that the user experiences delays and sluggishness when working with the form. The reduced performance experienced because of slow form rendering in the browser generally occurs at the following times:

    • When the form initially loads

    • When the form is updated and re-rendered after a postback response

    • When there is a change to the display of the form in the browser that does not involve a postback

    If the designer can reduce or eliminate conditions that are more expensive for the browser to render, the form will render more quickly, and feel more responsive to the user. As with other design issues we’ve examined that affect postbacks and server performance and scalability, addressing performance issues that affect browser rendering must be balanced with your unique design and business requirements.

    • Rich Text Box control

      The Rich Text Box control creates HTML elements for the content added to a rich text field. Depending on the amount of content and formatting added by the user it can end up creating a large number of HTML elements, which can impact browser performance. One issue with using a rich text field is that you cannot predict how much data a form user might add to the field. For example, a user could paste a large rich text selection into your form from just about any source. Although the Rich Text Box control for a browser-enabled form does not allow embedded images, only linked images, the content could still be quite large.

      Unfortunately, for browser-enabled forms the InfoPath Designer does not provide a way to limit the amount of data entered. Consequently, you should consider carefully how your users are likely to use any rich text fields you add to the form and limit the number of rich text fields that are visible in a view. If you need multiple rich text fields, consider using multiple views rather than putting them all on a single view. As an alternative, consider using a Multi-line Text Box control instead.

    • Nested Tables

      Rendering HTML code for tables is a relatively expensive operation for a browser. Nesting tables by inserting one table inside another, especially if they are nested several levels deep, compounds the complexity and is generally slow for a browser to render. For better rendering performance, consider using adjacent non-nested tables rather than nested tables.

    • Conditional formatting

      We looked at conditional formatting in an earlier article, touching on the interaction with postbacks to the server and how conditional formatting expressions fire each time the form is re-rendered. Since the browser must manipulate all the data, whether it is visible or not, this can be an expensive operation that makes the form display feel less responsive. While conditional formatting can be a useful design tool, there are times when the performance cost may outweigh the benefits. For example, if a form contains a large amount of data and a substantial part is hidden, the conditional formatting can slow the form display even though some of it isn’t rendered.

      In this case, designing the form with multiple views might improve the form’s display performance compared to the single view with hidden content. Although it will cause a postback each time there is a switch to another view, the user’s interaction with each of those views in the browser may feel more responsive. This is because each view has a smaller amount of data to render than the single view containing hidden data. The tradeoff you need to consider here is between the browser-side responsiveness of the form display and the server-side scalability of your form system as it processes postbacks: using conditional visibility might slow form display, but reduce the number of server requests, while using multiple views improves form display, but increases server requests and reduces scalability.

      As another example of how subtle performance tradeoffs can be, as noted in the earlier article, it is also possible to have a design where the form display is more responsive if it uses conditional formatting to hide some data. This is happens in a situation where the browser actually takes longer to render all the elements than it takes to process the conditional formatting and hide some.

      If you suspect you have a situation where conditional formatting could either help or hinder your form’s performance in the browser – or your server scalability – try alternate designs and test them to determine which design best meets your requirements.

    • Drop-Down List Box controls with many items

      Drop-Down List Box controls can generate a large amount of HTML, especially when there many items provided in the list. The amount of HTML balloons when the list control is contained in a repeating section or table. For example, if you include 50 items in a list, and the list is repeated 50 times, the underlying HTML code will grow very rapidly and slow down rendering of the form! Try to limit the number items in lists that are used in repeating elements or limit the number of repeating elements. Alternatively, you can try using conditional formatting, putting the repeating elements containing drop-down lists into a section that is hidden by default. Because they are not supported in browser-enabled forms, some of workarounds you might consider using if you are familiar with InfoPath rich-client forms, such as a Master-Detail control or one of the other list controls, are not available. About the only other alternative might be to emulate the list using a repeating table with each item on a row (and some fancy formatting). One situation to watch out for is using an external data source to provide the list items. If you need to do this, then you also need to make sure the number of items provided by the data source is limited to a reasonable number. As with any design, it is always a recommended best practice to test alternative designs for expected (and exceptional) data sizes to determine how your form designs perform.

    • Many visible controls

      Forms that have a large number of InfoPath controls visible in a view will reduce browser performance. Again, this is amplified when the controls are in repeating sections or tables. The first suggestion is to use multiple views so that each view has fewer controls to be rendered. If you use multiple views, make sure that controls are only bound once in the view in which they are used (use the Design Checker). Once again, you can also use conditional formatting to hide some of the controls, but this will typically achieve a smaller gain in browser performance compared to using multiple views. Because there are a number of important variables that determine browser rendering performance, your design alternatives should be tested in the common user environments you expect (data size, browser type, user's machine configuration) to determine acceptable number of controls and the relative performance of each design.

    • Calculations that use large data sets

      If you design a form that includes calculations and the data for the calculations is loaded from an external data source, then that data will be downloaded to the browser so that the calculation can run in the browser without a postback to the server. Normally this strategy improves overall performance by reducing postbacks. However, if the data set is large, the benefit of eliminating postbacks can be overtaken by the performance cost of handling the data in the browser. First, it is more expensive to load a large data set; second, it is expensive to run after it is loaded.

      If you find that the browser is too slow when running calculations with large data sets, you can force a postback so that the calculation runs on the server instead. In the InfoPath Designer, for the field that runs the calculation, add a button and change the postback setting to always require a postback. When the user clicks the button to run the calculation, it will postback to the server to evaluate the calculation and return the result to the browser for display. Like most performance suggestions, you need to balance performance in the browser with the performance and scalability of your form server system.

    • Reporting scenarios

      InfoPath is primarily designed to address form-filling scenarios. Although it can also be used to display data in a reporting scenario, this can have a negative impact on browser performance as the amount of data downloaded for display increases. If there is a possibility that the amount of data could be very large, then you can expect performance problems not only in the browser, but also on the server. Depending your ability to predict and limit the amount of data in a reporting form, it might be possible to maintain acceptable performance by using multiple views and read-only controls. However, if the data is too large or cannot be limited practically, you should consider an alternate reporting solution.

    • Internet Explorer 6

      If you have form users that are using Internet Explorer 6, they will experience reduced browser performance compared with other browsers due to known issues with IE6 JavaScript performance. You might consider providing a statement on your site about browser support, and if you know you have a substantial number of users running IE6, then it is a good practice to include IE6 performance testing in your development plans.

    Use the Design Checker to monitor browser compatibility issues

    The InfoPath Designer allows you to design forms that run in both the rich-client and a browser. When you are designing browser-enabled forms, and especially when you want your form to support running in both environments, you need to be careful about browser compatibility issues. As you are designing a form template in the InfoPath Designer, you can use the Design Checker task pane to monitor any browser compatibility issues detected by InfoPath, including those that affect performance.

    Among the messages displayed by the Design Checker are warnings for controls that will trigger postbacks to the server (these messages are hidden by default; to view them, select "Browser Optimization Messages" from the Options button at the bottom of the Design Checker). One or messages can appear for each control that will post back to the server when the value of the control changes.

    Sometimes the postback occurs because of a calculation, binding, or other expression on that control. Occasionally a control will post back to the server not because of a property on that control, but because that control is contained inside a section or a table where some other control forces a postback, or the control contains a section, table, or other controls inside it that cause a postback. In these cases, the warning messages indicate that you should look for another control marked as a primary cause of the postback; examining the messages for that control can help you locate, understand, and control postbacks caused by related controls.

    If having other controls bound to the same element or group are causing unwanted postbacks, consider using separate views, with the control bound once in each view.

    To resolve issues where the binding of the control requires server evaluation, or a node is listed as only available on the server, you might need to simplify your schema.

    You can change the default postback behavior for an individual control using the Postback settings options on the Browser forms tab in the Properties window for the control. There are three options available: Never, Always, and Only when necessary for correct rendering of the form (recommended). You can reduce the number of postbacks by changing the setting to Never. If you select Never, then the control will not send data to the server on change; the data will only go to the server and formatting, calculations, etc. will only run when the form user saves or submits the form, or another control in the form causes a postback to the server. For controls you want to change, you must change the postback setting option on each control individually; changing the option on a section or group control does not automatically change the value for every control inside it.

    Note that you should carefully consider the effect of changing postback behavior to ensure that the result is acceptable for your environment. Be careful about suppressing postbacks that affect the user’s form-filling experience to avoid issues where displayed data could be incorrect. You never want to sacrifice data integrity for a potential gain in performance. If you make any change to the postback settings, it should be thoroughly tested to ensure the form behaves correctly.

    What’s next?

    The next article in our series provides information on some of the useful performance monitoring counters that can help you evaluate the performance of your form system.

  • Microsoft InfoPath 2010

    "Design Once" and the new InfoPath 2007 Object Model

    One of the main design principles for InfoPath 2007 and Forms Services 2007 is that you can create your form once, write code for it once, build and publish it once, and then have it work in both the browser and the client. We call this Design Once.
    To make this possible for form templates with code, we created a new object model that works on both the client and the server, so that the exact same assembly can work in both places. This is similar to what the Compact .NET Framework provides for mobile devices, where you can write a WinForm app that works on both the desktop and a Windows Mobile smartphone. Using the InfoPath object model you can write code for your form that will run the same way both on client, when opened in InfoPath, and on the server, when opened in the browser.
    Getting started with System.Xml
    If you've written code for InfoPath 2003, then you're used to writing code against the MSXML-based object model. For example, you might read and write a field's value like this in C# with the old object model:
    string xpath = "/my:myFields/my:field1";
    IXMLDOMNode field1 = thisXDocument.DOM.selectSingleNode(xpath);
    string oldValue = field1.text; // Read
    field1.text = "New Value";     // Write
    Here's how to do the same thing using the new object model:
    string xpath = "/my:myFields/my:field1";
    XPathNavigator field1 = MainDataSource.CreateNavigator().SelectSingleNode(xpath, NamespaceManager);
    string oldValue = field1.Value; // Read
    field1.SetValue(“New Value”);   // Write
    If we break that down, we see the following mappings:
    InfoPath 2003 OM
    InfoPath 2007 OM
    Read field1.text
    Read field1.Value
    Set field1.text
    Set using field1.SetValue()
    Compatibility: Using the old OM in InfoPath 2007
    InfoPath continues to open forms that used the old object model, so you don't have to upgrade them just to use InfoPath 2007. That said, if you want a form to work in the browser, you will need to upgrade to the new object model. If you upgrade the code, InfoPath will automatically update the project format and rebind all your events, but you will need to convert your custom functions to the new OM.
    Compatibility: Using the new OM in InfoPath 2003
    The new object model won't work in InfoPath 2003, so we also allow you to create forms that use the old object model in InfoPath 2007. You can choose which version of the object model you want to use in Form Options in the Programmability category. 
  • Microsoft InfoPath 2010

    Free InfoPath 2010 Web Cast: Best Practices in Form Design


    The fourth and final session in the InfoPath 2010 Academy Live series, Best Practices in Form Design, by InfoPath PM lead Daniel Witriol takes place this Wednesday, May 5th at 8:30 AM (PST).

    You can sign up for this free Web cast on

    If you’ve missed any of our earlier sessions, you can watch them on demand at the links below:

    Academy Live

  • Microsoft InfoPath 2010

    Digitally Signed Fully Trusted Form Templates


    In the InfoPath 2003 Service Pack 1 Preview you can create a fully trusted form template by signing the XSN with a code signing certificate.  Here’s what you do:


    • While in the InfoPath designer, select Tools | Form Options | Security
    • Uncheck the “Automatically determine security level based on form’s design
    • Select Full Trust
    • Click the Sign this form button

    At this point, you need to choose a certificate that can be used for code signing.


    If you do not have a certificate, you can choose the Create Certificate button.  This will create a test certificate – not a certificate that has been authenticated by a certificate authority.


    While you are developing your form template, you will not be able to preview with full trust permissions unless you register the form template. 


    The first time your users fill out the form that you have signed with a certain certificate, they will see a Security Warning dialog that notifies them that the form template is digitally signed and asks if they trust the publisher.  Once they have checked the box to trust the publisher, they will be able to open any form template that asks for full trust and is signed with that same certificate.


    You can view the list of trusted publishers in the SP1 version of InfoPath by selecting Tools | Options and clicking on the Trusted Publishers button.


    If users find that the option to trust the publisher is disabled, that means that the root of the certificate used is not trusted on the user’s machine. 


    When you received your code-signing certificate, you asked the CA (Certificate Authority) for it. What the CA delivered to you is a certificate that is now in your personal folder that is trusted by you and by anybody who trusts the CA that issued it.  So, for example, if you get a code signing certificate from Verisign, any user will have the option to trust you as a publisher as long as they also have Verisign in the list of Trusted Root Certification Authorities on their machine.  Once a user has trusted the root of a certificate, the option to trust the publisher will be enabled in the Security Warning dialog that is displayed when they fill out a fully-trusted, signed form.


    Users can trust the root of a certificate through the Security Warning dialog that comes up when they open a form template.  When the Security Warning dialog is open:


    • Click on the Details button
    • Click on the Certification Path tab
    • Click on the CA Root Certificate
    • Click View Certificate button
    • Click Install Certificate
    • Follow through the Certificate Import Wizard
    • After the import is successful, close out of all of the dialogs
    • Open the form to fill out again and when the Security Warning is displayed the option to trust the publisher should be enabled.



  • Microsoft InfoPath 2010

    Sorting Repeating and Tabular Data


    InfoPath is a great way to easily gather and present XML data to the masses. But what about efficiently presenting a massive amount data? Tons of data (e.g., a list of hundreds product names) usually find their ways into lists that we’ll find on SharePoint, in a database, or just sitting in an XML file. Controls like Repeating Sections and Tables are useful mechanisms for displaying lists of data. But their usefulness is limited to how efficiently the user of your form can find and work with such large lists of data. An easy solution to effectively present large lists of data to your users is through sorting that data.

    No Sorting Options in InfoPath
    Try scouring the Repeating Table or Repeating Section controls’ properties dialogs for anything related to “sort”. Sorry to say, you’ll come up empty handed. That’s why we thought you’d find this blog entry handy. Our goal is to show you how to sort any repeating data and to do so in many different ways: sort by string, sort by number, sort ascending or descending, and even sort by different fields (or columns) in the repeating data. What we’ll show you, in both the code and the design of the view, is designed to be browser-compatible. This means you can publish this form template to a SharePoint server running Forms Services 2007 and fill out the form in a Web browser. Let’s get started.


    Figure 1: Filling out the SortingPeople sample form template

    The sample form template is attached; download the ZIP to your desktop, expand it, then right-click the XSN and select "Open in Design Mode". This sample requires InfoPath 2007, and will work in the browser when published to InfoPath Forms Services.

    The View for the SortingPeople Form Template
    To show you how to sort data in your form, we’ll use a concocted example to sort a list of people. As you can see in Figure 1, there are various options to sort the data. Clicking the “Sort” Button triggers the sort otherwise the data is not sorted automatically (more on this later). You can also sort by clicking any of the “Sort by this column” Buttons in the header and footer of any column. There are three columns in the Repeating Table representing our repeating data: Last Name, First Name, and Age. (The string data type is used for the first two columns and an integer data type for the last column.) In Figure 1, we’ve filled out the form with names of famous architects. (Their ages are fictitious.) While we’re not working with enough data to really justify a sort, this example is simply for demonstrative purposes. As you might expect, we can sort the Repeating Table data by any column and by any direction (ascending or descending). At any time we can change the existing data or even add or remove rows. But we would need to invoke the sorting functionality to put things into place again.

    The Data Source for the SortingPeople Form Template
    To begin designing this form template we started with controls and the data source. We inserted a Repeating Table control and renamed its data source groups and fields to map with our people example. The main data source is shown in Figure 2. To accommodate the various sorting options that we expose via controls at the top of the view (e.g., the Sort By Drop-Down List Box), we’ve added attribute fields under the SortingPeople document element. These attribute fields remember, for example, whether we’re sorting by the Last Name or the Age column.

    Figure 2: Data source for the SortingPeople sample form template

    Considerations When Sorting Data
    Now we’ll look at how we implemented sorting functionality behind this form template. This is accomplished through C# code behind the form. While we could have opted for an easier XSL-based implementation to sorting data, it would not have been compatible with Forms Services. So we’re left to actually sorting the data. There are advantages as well as disadvantages to our approach. Sorting the data is preferred when you want to persist the sorting in the saved or submitted form. While the initial cost is much higher to sort the data in the data source instead of the view, there is much less processing that occurs on subsequent visits to that data because it will already be sorted. If your form template has multiple views, switching to and from a view that performs an XSL sort is very expensive. On the contrary, a sorted data source adds no additional processing requirements on view switches. A final reason why you may want to sort the data in the data source instead of the view: submitting sorted data to a database or Web service may be optimal (or even a requirement) for that backend system.

    Sorting Data with C# Form Code
    To best understand how we designed the code behind form template to support sorting, we’ll be talking about its C# form code and how it interacts with the main data source. Let’s start by looking at some of the supporting form code that will make it easier for us to implement the sort feature. The properties are used within the sort itself to read the options at the top of the view about how to sort the data. The methods are very useful helpers that we use throughout our sample code.

    /// <summary>

    /// Returns the "Sort By" Drop-Down value.

    /// The value returned by this property MUST match with an item within the Repeating Table.

    /// </summary>

    private string SortBySelection


        get { return GetValue("@my:SortBy").Replace(" ", string.Empty); }



    /// <summary>

    /// Does the user want the SortBy by number (true) or string (false)?

    /// </summary>

    private bool SortAsNumber




            return 0 == GetValue("@my:SortAs").CompareTo("number");




    /// <summary>

    /// Does the user want an ascending (asc) or descending (des) sort?

    /// </summary>

    private bool SortAscending




            return 0 == GetValue("@my:Order").CompareTo("asc");




    /// <summary>

    /// Helper to wrap an int within brackets.

    /// </summary>

    /// <param name="intToWrap"></param>

    /// <returns></returns>

    private string WrapAsIndexer(int intToWrap)

    { return WrapAsIndexer(intToWrap.ToString()); }


    /// <summary>

    /// Helper to wrap a string within brackets.

    /// </summary>

    /// <param name="strToWrap"></param>

    /// <returns></returns>

    private string WrapAsIndexer(string strToWrap)

    { return "[" + strToWrap + "]"; }


    /// <summary>

    /// Helper to get an XPathNavigator's value.

    /// </summary>

    /// <param name="xpath"></param>

    /// <returns></returns>

    private string GetValue(string xpath)


        return Root.SelectSingleNode(xpath, NamespaceManager).Value;



    /// <summary>

    /// Helper to set an XPathNavigator's value.

    /// </summary>

    /// <param name="xpath"></param>

    /// <param name="value"></param>

    private void SetValue(string xpath, string value)


        Root.SelectSingleNode(xpath, NamespaceManager).SetValue(value);



    /// <summary>

    /// Helper to get the document element of the main data source.

    /// </summary>

    private XPathNavigator Root


        get { return CreateNavigator().SelectSingleNode("/my:SortingPeople", NamespaceManager); }


    Next, let’s take a look at the code behind all of the Buttons in our form template. We created these event handlers through each Button’s properties dialog. Their implementations are quite trivial. You can see that adding additional sorting columns to the Repeating Table is a simple task. If you wanted to add a column that doesn’t need to be sorted, there’s nothing to do beyond adding the column in the Table!

    public void SortButton_Clicked(object sender, ClickedEventArgs e)





    public void LastNameSort_Clicked(object sender, ClickedEventArgs e)


        SetValue("@my:SortBy", "Last Name");




    public void FirstNameSort_Clicked(object sender, ClickedEventArgs e)


        SetValue("@my:SortBy", "First Name");




    public void AgeSort_Clicked(object sender, ClickedEventArgs e)


        SetValue("@my:SortBy", "Age");



    Now the million dollar question: what’s behind the SortList method? Let’s look and then we’ll explain how it works.

    /// <summary>

    /// Bubble sorts the list of people.

    /// </summary>

    private void SortList()


        string sortBy = SortBySelection;

        string itemsToSort = "my:People/my:Person";

        System.Globalization.CultureInfo currentThreadCulture =



        int numPeople = Root.Select(itemsToSort, NamespaceManager).Count;


        // basic bubble sort implementation

        for (int i = 1; i < numPeople; i++) // xpath is 1-based


            for (int j = i + 1; j <= numPeople; j++) // keep j ahead of i; we can index [numPeople]


                // swap (i,j) if necessary

                string iValue = GetValue(itemsToSort + WrapAsIndexer(i) + "/my:" + sortBy);

                string jValue = GetValue(itemsToSort + WrapAsIndexer(j) + "/my:" + sortBy);


                // Do we sort by number or string?

                if (SortAsNumber)


                    int iNum, jNum;

                    if (!Int32.TryParse(iValue, out iNum) || !Int32.TryParse(jValue, out jNum))


                        // Let InfoPath take care of the invalid datatype with its own validation, we'll keep sorting the rest




                    if ((SortAscending && iNum > jNum) || (!SortAscending && iNum < jNum))


                        Swap(itemsToSort + WrapAsIndexer(i), itemsToSort + WrapAsIndexer(j));



                else // SortAsString


                    if ((SortAscending && String.Compare(

                        iValue, jValue, true /*ignoreCase*/, currentThreadCulture) > 0)

                        || (!SortAscending && String.Compare(

                        iValue, jValue, true /*ignoreCase*/, currentThreadCulture) < 0))


                        Swap(itemsToSort + WrapAsIndexer(i), itemsToSort + WrapAsIndexer(j));



            } // end inner-for

        } // end outer-for


    Analyzing the C# Form Code
    Let’s break down what we’re doing in this SortList method. First we get the column to use for sorting, the XPath to the repeating group that we want to sort, and the culture of the thread so we respect the current locale when sorting. Next we get the number of people that we’ll be sorting. We need this number because we’ll use it for our bubble sort implementation.

    The two nested for-loops implement the bubble sort algorithm. We chose bubble sort because of its simplicity and for demonstrative purposes. (We’d recommend you use the most efficient sorting algorithm based on your requirements.) The variables i and j iterate through the people. We use the iValue and jValue variables to select the data pointed at by i and j to determine if a swap is necessary as part of the sort loop.

    Next, we have an if-else statement that checks if the sort is by string or by number. A sort by number will attempt to parse out 32-bit integer values from the iValue and jValue fields. If the parse fails for any reason, we skip this specific comparison and continue trying to sort the rest of the data. Once we have integers, we do a simple comparison and swap if needed. If we’re sorting by string instead of numerical value, we use the static .NET library String.Compare method to make a culture sensitive comparison. A swap is performed if it’s necessary. (Note that we could have combined some code in the SortList method to make it more compact. We left the structure of the code unoptimized for maximum readability.)

    The last bit of code we have not yet revealed is the Swap method. This method, as its name suggests, simply swaps the positions of two XPathNavigator objects as identified by their XPaths. (An XPathNavigator is a pointer into an XML tree of data. You can read more about the XPathNavigtor class on MSDN.)

    /// <summary>

    /// Swaps two XPathNavigators at xpath1 and xpath2.

    /// </summary>

    /// <param name="xpath1">First XPath.</param>

    /// <param name="xpath2">Second XPath.</param>

    private void Swap(string xpath1, string xpath2)


            XPathNavigator item1 = Root.SelectSingleNode(xpath1, NamespaceManager);

            XPathNavigator item2 = Root.SelectSingleNode(xpath2, NamespaceManager);


            // Make a copy of item1

            XPathNavigator item1Clone = item1.Clone();

            // Move item2 to item1


            // Make the original item2 be item1 that we cloned earlier



    Sorting Automatically
    One of the things you might ask is why we decided against sorting the data automatically. The most important reason is user experience and then followed by form responsiveness. Think about what would happen if the Repeating Table rows sorted themselves whenever data changed that required a sort. Say you were entering data into a new row. You start by typing a person’s last name and then either hit tab or click into the First Name field. If the form is sorting by the Last Name field, the row may have jumped to another location relative to the other rows in the Repeating Table! You would expect that you could fill in all of the data for a new row before it sorts itself. There are also other weird cases that automatic sorting would spoil. For example, you would not see a new row added within the middle of the Repeating Table. Why? As soon as you added it, it immediately jumped to the top (or bottom) of the Repeating Table as sorted data. Let’s consider for a moment why we didn’t automatically sort because of form responsiveness; for now let’s assume that we somehow worked out all of the kinks with the user model. Obviously the form will be less responsive in InfoPath, especially on a slow computer, with so much sorting. But the real problem is realized when filling out such an intense form template in a Web browser. Every time code runs while a form is filled out in a browser, the form data is posted back to the server for processing. Postbacks themselves can take several seconds or even minutes depending on many variables including the network connection speed as well as the client and server machines’ performance capabilities. As you can see, an automatically sorting form isn’t necessarily a better form.

    Hagen Green
    Software Design Engineer in Test

  • Microsoft InfoPath 2010

    Microsoft Office InfoPath 2003 Toolkit for Visual Studio 2005


    Visual Studio 2005, SQL Server 2005, and BizTalk 2006 all launched on Monday.

    That means the Microsoft Office InfoPath 2003 Toolkit for Visual Studio 2005 is now available as part of the Visual Studio 2005 Tools for the Microsoft Office System.

    To install the Toolkit, run setup from the CD labeled "Microsoft Office InfoPath 2003 Toolkit for Visual Studio 2005" that is included with the Visual Studio 2005 Tools for Office package, or from the separate related download for MSDN Subscribers.

    Find out more here:


  • Microsoft InfoPath 2010

    Where do UDC files come from?

    Where do UDC files come from? - I knew you’d ask. (For those of you who are wondering what a UDC file is, you should go read my post entitled "Making data connections work in browser forms.")
    There are a couple of ways to go about it. UDC files are just xml files with a specific namespace and schema, so once you have a few examples you can probably get around handily with notepad and cut and paste. However, we’ve made it easier than that with the new Convert functionality on the Manage Data Connections dialog. (For those intrepid souls who prefer the notepad route, a schema reference is being prepared for publication.)
    If you start out by designing your data connection the way you normally would, you can then use the Convert button to change the connection from settings in the form template to settings in a data connection file. (In fact, you can open any existing form template in InfoPath 2007 and convert existing data connections the same way.)
    To start with, make sure you have write permissions to a data connection library (henceforth "DCL") on the Microsoft Office SharePoint 2007 server you’re going to publish your form to. Then, using InfoPath 2007 Beta 2 or later, create your data connection or open a form template with an existing data connection. Make sure the connection is to a source supported by UDC. (E-mail connections, connections to a Microsoft Access database, or connections to an XML file in the form template cannot be converted to UDC connections.)
    Here’s the data connections dialog showing a few connections I threw together (you can get to this dialog off of the "tools" menu in InfoPath design mode):
    Click the Convert button and specify the path to your data connection library. If you click "Browse...", InfoPath will suggest a filename based on the name you gave the data connection when it was created.
    If you choose a data connection file that already exists, InfoPath will use the settings in the file you chose - don’t expect it to overwrite the original file with new settings. This could have unexpected results if the file that’s already in the library is a different connection type or returns data that does not conform to the schema your form template expects.
    For most cases, you want to leave the default connection link option. Choosing "centrally managed connection library" will cause InfoPath and Forms Services to look for the UDC file in the "Manage data connection files" library in SharePoint central admin. This is fine, but it means that you need to copy the file from the DCL where you created it to that location before you can use it. This presumes you have access to SharePoint Central Admin. See my last blog post entitled "Making data connections work in browser forms" for more information on this option.
    Once you click "OK" on this dialog, your UDC file will be created and saved to the location you specified, and the connection in the form template will be modified to retrieve settings from the UDC file rather than from the form template.
    NOTE: There’s a known issue in the Beta 2 release where you will see an "invalid URL" dialog at this point. This is benign and is no longer seen in the technical refresh.
    You now have a UDC file in your DCL, but you’re not quite done. By default, a DCL will require content approval before anyone other than the file’s owner can use the UDC file you uploaded. Unless the content approval requirement has been removed, a site administrator or someone else with the content approval right will need to set the file’s status to "approved."
    Adding Authentication
    InfoPath does not automatically configure server-only authentication options for you. However, when creating a UDC file, InfoPath automatically creates an authentication block within the UDC file that is preconfigured to use Office Single Sign-on. In order to use this authentication option, you’ll need to uncomment the authentication block within the file and add both the SSO application ID and the CredentialType. Most of the time, you’ll want to use the SSO credential to log onto Windows, for which you’ll need to specify "NTLM" as the CredentialType. The full list of possible credential types is as follows:
    Credentials will be embedded in a database connection string for authentication against a SQL server.
    Credentials will be used to impersonate a Windows user
    Credentials will be used to impersonate a Windows user using Kerberos
    The username will be used to impersonate a Windows user using Constrained delegation
    Credentials will be used to perform HTTP Basic authentication
    Credentials will be used to perform HTTP Digest authentication
    Reusing existing UDC files
    Once you’ve created your UDC file, you may want to use the same connection for other form templates. Among other things, this has the benefit of sharing settings for multiple forms in a common location. Changing the settings in the UDC file will cause all of the related forms to pick up the changes the next time they are used.
    There are several places in InfoPath where we expose the ability to re-use data connection settings exposed as UDC files in a data connection library. Here are a few examples:
    All of these entry points lead to this dialog:
    When you specify one or more SharePoint sites to search, this dialog allows you to browse available UDC files containing in DCLs on those sites. Based on the context, this dialog is filtered to show only applicable connections (for example, if you start from the "Design a form" dialog, this dialog will only show Web service and database connections).
    Once you’ve specified the UDC file to use, you may need to specify some properties for the connection that are not contained in the file (for example, for a SharePoint list connection, you’ll be asked to specify which columns to include in the data source), but otherwise, you’re done.
    - Nick Dallett
    Program Manager
  • Microsoft InfoPath 2010

    Template Parts 101


    So, you’ve heard about this new InfoPath 2007 feature called template parts. You may have even found the option to design one in the Design a Form Template dialog. But what you can do with it and why you would want to bother.. well that’s just a big mystery. So, I’m here to help you out.

    Template parts are simply mini form templates: you can add layout, controls, rules, data validation, conditional formatting and data connections. Once built, you can include template parts in other form templates so that you only have to build common components once. When you need to make changes, you change the template part and then update its version within the form templates using it. You don’t have to make the modification numerous times. Common scenarios for template part use include:

    • Company letterhead
    • Employee information (address, phone number)
    • Purchase order

    How to build a template part

    Template parts are built in the same way that form templates are built, though there is a slight difference in how you get started. Because there are some limitations in what you can put into a template part (see "What template parts don’t do" below), they are built in a separate mode from regular form templates. This allows you to be sure that whatever you put into the template part will function as intended. At the Design a Form Template dialog, select the Template Part radio button:

    Note that you can also choose whether or not the template part will be used in browser-enabled forms. If you aren’t sure, err on the side of caution and select “Enable browser-compatible features only”. This will ensure that you can use the template part in both client-based and browser-compatible forms.

    Click OK and you can now design your template part as you would any other form template. When you are finished, save the template part (you will end up with a file ending in .xtp) and send it out to whoever you would like to use it.

    How to use a template part

    To actually put a template part into a form, you must first install it on your machine. This sounds a whole lot scarier than it actually is. All you need to do is click on the “Add or Remove Custom Controls…” link at the bottom of the Controls task pane and follow the instructions that appear:

    Once you’ve done this, the template part will show up in the Custom Controls area of the Controls task pane. You can now insert the template part into your form as you would any other control. Once your template part has been inserted, you can also make modifications to it that are specific to that form.

    How to update a template part

    When you make changes to a template part that is already in use, you must redistribute the template part. The people using it must then install the new version (see “How to use a template part” above) and update the ones in their forms. Once the new version is installed, template parts in the form will automatically notice that there is a newer version available. You can then right-click on the template part and select Update. If you have made any changes to the template part within the form itself, these changes will be overwritten by the update.

    What template parts don’t do

    Here are some of the things that you can’t do with template parts:

    • Script and managed code
    • ActiveX controls
    • Submit data connections
    • IRM
    • Multiple views

    The more complete list is available on Office Online. The general pattern is that anything that would be a form-level property is not available in template parts.

    I hope you will find template parts to be useful and a mite less mysterious than they were before.

    Happy form designing,

    Bojana Marjanovic
    Program Manager

  • Microsoft InfoPath 2010

    Extended data validation for the Multiple-Selection List Box in InfoPath 2010


    Hi, Frank Mueller from the InfoPath development team here. The Multiple-Selection List Box (MSLB) control was introduced in InfoPath 2007 to enable users to select multiple items from a list when filling out forms. In this post, I will explain the different ways you can restrict and validate the data entered using this control in InfoPath 2010. I will also cover some advanced tips and tricks.

    In this post:

    Data Validation

    Special behavior in SharePoint List Forms

    Removing Blank Default Values

    Example Usage:

    First let’s look at a scenario where you may want to use the MSLB control. Say, for example, you are building a form for customers to order your company’s products. To be able to more effectively spend the company’s marketing budget in the future, the marketing department would like to know how your customers found the company’s web site. So you’ve added a Multiple-Selection List Box to gather responses to that question.

    Multi-select list box

    Your customers can now select one or more options. If a customer heard about the web site through a channel that is not specified in the Multiple-Selection List Box control, he/she can select the last checkbox and just type in a custom response.

    Data validation

    The marketing department is pleased with the new order form, but many customers do not bother responding to the “How did you hear about us?” question. With InfoPath 2010, solving this problem is very easy.

    In InfoPath 2010, there are two main ways that form designers can restrict and validate the data entered using the MSLB control.

    1. Require that at least one item be selected (At least one selection required) (NEW in InfoPath 2010)
    2. Require that every selected item have a value (Cannot be blank)

    Multi-select list box Properties

    Require that at least one item be selected (At least one selection required) (NEW in InfoPath 2010)

    New in InfoPath 2010, we can now enforce that users select at least one non-blank item by setting the “At least one selection required” property. In most cases, this is the setting that you will want to use.

    When you preview the form, you will notice a red asterisk in the upper right corner of the control, indicating that a selection is required.

    Multi-select list box If you select a blank custom value, an asterisk will appear in the top right hand corner of the custom value text box.

    Multi-select list box All asterisks will disappear as soon as you select an option that is not blank, or you select the custom value text box and type in a value.

    Technical Details

    The new type of data validation is only applicable to repeating fields that are bound to Multiple-Selection List Box controls.

    When setting the property at the field-level (instead of on the control), you will notice that it’s called “Non-empty occurrence required”. This is because the field can be bound to a control other than the MSLB, in which case users do not make selections when using the control.

    You may set any repeating field to “Non-empty occurrence required”, but you will only see an effect when the field is bound to a Multiple-Selection List Box control. “Non-empty occurrence required” is not implemented as an XSD constraining facet, but rather as a special Validation Rule that is stored in the manifest.xsf of your form template. This has the benefit that you can set the data validation even if you are designing a form template based on a locked schema.

    Require that every selected item have a value (Cannot be blank)

    In most cases, the “At least one selection required” property will do you what you need to ensure that users enter the required data.
    In InfoPath 2010, we still support the legacy “Cannot be blank” property. When this property is set, it requires that every item that a user selects from the list has a value. It does not however require that users select an item in the first place.
    When you preview the form, you will notice a red asterisk, whenever you select the checkbox of the custom value text box. This indicates that if the user wants to select this option, a value has to be typed in the text box before the form can be submitted. Once you type some text in the custom value text box, the asterisk will disappear.

    Multi-select list box

    Technical Details

    When a field in an InfoPath form is set to “Cannot be blank”, a minLength constraining facet is applied to the XSD element, which requires that corresponding XML nodes contain at least one character.

    <xsd:element name="field1" type="my:requiredString"/>   
             <xsd:simpleType name="requiredString">
                      <xsd:restriction base="xsd:string">                           
                              <xsd:minLength value="1"/>

    This makes sense for text fields, when the form designer wants to ensure that the person filling out the form has to enter data into the field before it can be submitted for further processing.
          First Name
    The Multiple-Selection List Box control is bound to a repeating field in the form’s data source. When the user fills out the form and makes selections in the control, a new XML node is created for each selection made. If you mark the repeating field that the control is bound to as “Cannot be blank”, InfoPath will ensure that all options selected or entered through the custom value textbox are not blank. However, if no selections are made in the control, no XML nodes are created, and hence the constraining facet of the field is not violated, and the user is not forced to make a selection.

    When would I want to use “Cannot be blank” instead of “At least one selection required”?

    If you want to ensure that users do not select any item that does not have a value then the “Cannot be blank” property can be used.

    In the example below, both “At least one selection required” and “Cannot be blank” are set. The data is not valid because the custom selection is blank.

    Multi-select list box

    In the example below, only the “At least one selection required” is set. The data is valid because at least one non-blank item is selected.

    Multi-select list box

    Advanced Information:

    Special behavior in customized SharePoint list forms

    In a SharePoint list, when you mark a Choice column as required, it requires users to select at least 1 item and for all selected items to have values.

    SharePoint Column Settings

    Marking the field as required in SharePoint, has the same effect as setting both the “Cannot be blank” and “At least one selection required” properties in InfoPath.  For consistency with SharePoint, when customizing a SharePoint list form in InfoPath 2010, only one data validation option, “Cannot be blank” is available.

    Removing Blank Default values

    When designing the order form described above, InfoPath will by default insert a blank default value node for each repeating field. As you preview the form you will notice that the custom value text box at the bottom of the Multiple-Selection List Box control will be checked by default.

    Multi-select list box

    If you wish there to be no default selection at all in the control, you need to remove the default value node.

    1. Click on the File button
    2. Select Form Options under the Form Information tab
    3. Select the Advanced category in the Form Options dialog
    4. Click on the Edit Default Values … button
    5. Click on the pluses in front of the fields to expand the data source until you can see the repeating field that is bound to the Multiple-Selection List Box control
    6. Uncheck the checkbox in front of the repeating field

      Edit Default Values

    7. Click OK to close both opened dialogs
    When you preview your form now, you will notice that the custom value checkbox is not selected by default.

    Multi-select list box

    Frank Mueller
    InfoPath Developer

  • Microsoft InfoPath 2010

    Data binding between Document Information Panel and Word document

    The Document Information Panel is a Microsoft Office InfoPath 2007 form that is hosted and displayed in a Microsoft Office Word 2007, Microsoft Office Excel 2007 or Microsoft Office PowerPoint 2007 document. It enables users to view and edit properties of a document or a content type that is associated to a document management server.
    In Microsoft Office Word 2007, users can add properties from Document Information Panel as content controls to document surface. This is also known as data binding between Document Information Panel and Word document. Users can bind Document Properties, Server Content Type Properties or Custom Properties. Once the data is successfully bound, users can edit the properties from Word document surface.
    This article will demonstrate two ways to bind data from Document Information Panels to Word document surface.
    Method 1: Binding Document Properties or Server Content Type Properties to document surface
    1. Launch Office Word 2007
    2. File | Open to open any Document Information Panel document
    3. Place IP in the document where you want the property control to be
    4. Click Ribbon UI Insert | Quick Parts | Document Property
    5. Choose the property you want to add:

    You now have a content control in Word surface that binds data to Document Information Panel property. Please note that this method also works for Server Properties, but you need to save or associate the document with the Server document library first. Then you will see Server Properties in Quick Parts | Document Property list.
    Method 2: Binding Custom Properties to document surface
    For non-document or non-server related properties, which are defined as Custom Properties in this blog, there is no UI to bind these properties directly to document surface. Users need to use Word Object Model to do the data binding.
    Assume the Custom Document Information Panel has the following data structure:
    Here are the steps to bind the costCenterID property to Word document.
    1. Launch Microsoft Word 2007
    2. File | Open to open a document that contains this custom Document Information Panel
    3. Press Alt+F11 to launch Microsoft Visual Basic editor
    4. Press Ctrl+G to launch the Immediate window
    5. In the Immediate window, add a Text content control by triggering the following command:
    ActiveDocument.ContentControls.Add wdContentControlText
    1. Set up this content control XML mapping to costCenterID node by triggering the following command:
    ActiveDocument.ContentControls(1).XMLMapping.SetMapping "//*[local-name(.)='costCenterID']",, ActiveDocument.CustomXMLParts(4)
    Here the SetMapping function takes three arguments. First input is the XPath of the node you plan to do a mapping.  Second one is PrefixMapping input. Last one is Custom XML Part source where the node belongs to. In this case, costCenterID node lives in 4th custom XML part.
    1. Switch back to Word active document window. The content control should get set up.

    Now you have successfully set up properties mapping between Document Information Panel and Word document. When you edit the properties from Word document, the value is updated in the Document Information Panel automatically or vice versa.
    If you'd like to know more about the Document Information Panel, be sure to check out this webcast.
    Emily Ching
    Software Design Engineer in Test
  • Microsoft InfoPath 2010

    Consuming Excel Data using InfoPath Database Data Connections


    InfoPath data connections can be one of the most powerful features of the product.  However, sometimes the out-of-box support for various data sources just doesn't seem to cut it when you get out into the field.  How in the world can I get data from an Excel spreadsheet  into my InfoPath form?  A typical response might include externally automating Excel via COM or the managed PIA to create InfoPath forms.  Or you might try using the Excel 2003 XML spreadsheet file format with the InfoPath XML data connection.  While both solutions are feasible, they can be a bit clunky to manage multiple files generated from your spreadsheet…
    Here is your question answered!  Access 2007 provides support for linked tables, virtual tables that pull data from a data source external to an Access database.  Since InfoPath has a built-in database data connection that can query data directly from an Access database, Access 2007 can effectively act as a router for data sources that aren't directly supported by InfoPath.  In this post, we'll step through setting up an InfoPath database data connection that queries data from an Excel spreadsheet.
    Prepare your Excel spreadsheet
    Once you've added all the necessary data to your Excel spreadsheet, save the Excel workbook to a shared network location that will be accessible to all users filling out your InfoPath form.
    Create the Access database to link the Excel data
    Launch Access 2007 and create a new blank database.  When you create a blank database, a default table will be created.  Go ahead and delete the table (just closing the query view should remove the table.)
    Switch to the "External Data" tab in the Ribbon


    Click the "Excel" icon in the "Import" chunk to launch the "Get External Data - Excel Spreadsheet" wizard.
    Browse to the Excel workbook that you saved in the "Prepare your Excel spreadsheet" section, above.
    Select "Link to the data source by creating a linked table" and then click "OK".


    Choose the Sheet or Named Range that you want to import, then click "Next >". If the first row of the spreadsheet contains column headers, check the "First Row Contains Column Headings", then click "Next >".

    Type a name for the linked table (I'll call it "Spreadsheet" for this post), then click "Finish".
    Click "OK" when Access tells you it's done linking the table.  When the dialogs close, you'll see the linked table listed in the "All Tables" task pane


    Save the Access database to the same directory where the Excel file was saved, then close Access.
    Design the InfoPath Form Template to Query the Linked Table
    Design an InfoPath Form Template based on a "Database" (you could also add the data connection as a secondary database data connection in an existing form template).


    Once you've clicked "OK", the "Data Connection Wizard" will open.  Click "Select Database…" to open the "Select Data Source" file browser dialog.

    Click "New Source…"

    NOTE: At this point, it's tempting to just browse to the Access database as you normally would.  However, the default provider used in that case does not support linked tables, so InfoPath will see no tables in the database.  In order to select the appropriate provider, you have to click "New Source…"


    Select "ODBC DSN", then click "Next >".
    Select "MS Access database", then click "Next >".

    Browse to the Access database that you created in the "Create the Access database to link the Excel data", above, then click "OK".

    NOTE:  This browse dialog can be a bit confusing.  If you get mixed up by the unusual browsing experience, you can just type or paste the full path to the database in the "Database Name" field (boxed in green in the screenshot below).


    Select the name of the linked table, then click "Next >"
    Finish the data connection wizard as you would for any other database data connection.
    At this point, you're good to go.  The data connection to your Excel data will behave the same as a query-only Access database data connection.

    - Forrest Dillaway, InfoPath Test


  • Microsoft InfoPath 2010

    Designing browser-enabled forms for performance in InfoPath Forms Services (Part 2)


    Part 2 – Postbacks and conditions that cause them

    Welcome to the second article in our series on optimizing the performance of browser-enabled forms designed with Microsoft Office InfoPath 2007. In our first article, we defined performance in terms of responsiveness. In this article, we’ll focus on postbacks, one of the most common causes of reduced performance

    Postbacks are probably the most important factor affecting form performance because the effect of other conditions is amplified with each postback. There are two significant aspects of postbacks which we’ll examine in this series. First, which form features cause postbacks? Those features are the subject of this article. Second, what kinds of postbacks are more expensive to process, thus imposing an additional burden on the performance and scalability of the form system? We’ll examine those factors in the next article.

    What is a postback?

    Certain form controls, actions, and features require the browser to communicate with the server during the form-filling session. This exchange of data during the session is called a postback, and usually occurs when a form feature needs to send data to the server for processing. After sending the postback request, the browser must then wait for a response before it can update and re-render the form with the new data. In the case of a full-page postback, the browser must stop rendering completely until the whole updated page is returned, blocking user interaction with the form until it has been re-rendered. Alternately, to improve the user experience in the browser, some features use a partial postback, where only a specific part of the form is updated. This allows the user to continue interacting with other parts of the form while the update happens in the background. In either case, however, unnecessary postbacks impose an additional load on both the browser and the server. If you can reduce or eliminate postbacks as you design, develop, and test your forms, you can improve the performance and scalability of your entire form system.

    Browser-enabled form handling compared with InfoPath client forms

    To better understand the effects of postbacks on performance, it is helpful to compare basic form handling of the InfoPath-rich client with InfoPath Forms Services and browser-enabled forms. Whether you are new to InfoPath, or you are familiar with rich client forms but new to InfoPath Forms Services and browser-enabled forms, understanding these basic differences will help you improve your form design and troubleshooting strategies.

    The major difference between the InfoPath-rich client and browser-enabled form systems is that the InfoPath client doesn’t need to communicate with the form server as frequently as the browser does. This is because the InfoPath client processes most forms locally on the user’s computer. In contrast, the browser form relies on the server for a variety of form processing operations, requiring more communication to exchange data between the browser and the form server. Communication in the form of postbacks is a fundamental feature that allows InfoPath to support browser-enabled forms on the Web, but postbacks also make browser forms more sensitive to performance issues.

    Let’s look at two form loading and editing scenarios that further illustrate the difference between form processing in the InfoPath client and browser-enabled form systems.

    In the InfoPath-rich client scenario, when the user opens the form from a SharePoint form library, InfoPath first determines that the form should be opened in the client rather than the browser. After the initial download of a copy of the requested form template, InfoPath opens and renders an instance of the form on the user’s computer for editing. The form instance in the client is an XML document that the client renders in HTML for display. As the user interacts with the form, the InfoPath client processes and renders changes, and might run some custom form code, all within the context of the client running on the user’s computer. Generally, the only time the client needs to connect back to the server is to make additional data connection requests to query from or submit to a data source, to save a partially completed form, or to submit the final form.

    In the case of the browser-enabled form, when InfoPath Forms Services receives an initial request for the form from the browser, the server starts a session for that user’s form-filling session, allocates server resources, and processes the browser-enabled form template to load an instance of the form XML for the session. In addition, if the form requires it, the server might load and run custom form code and load data from a data source. After this initial processing, the server assembles the JavaScript and HTML that represent the form instance to be downloaded to and rendered by the browser.

    Finally, the server sends the response through a Web Front End server over the network to the browser on the user’s computer, which renders the initial download into the form view that the user interacts with. As the user interacts with the form in the browser, some form processing happens in the browser, but more complex form elements and events require a postback to the server for processing.

    During the transmission and processing of the form data, the browser instance of the form must wait for a response and then re-render the updated form. In this communication cycle, each postback request and response set constitutes a roundtrip. Each roundtrip affects the performance and scalability of the form system in terms of throughput, responsiveness, and resource utilization. This impacts both the browser side and the server side, as well as the network.

    As you can see from these two scenarios, a form-filling session in the browser-enabled form system requires substantially more communication than a similar session in the InfoPath client. In addition, more of the browser-enabled form processing is concentrated on the server, especially when multiple form-filling sessions are being served. In contrast, with an InfoPath client form, the form processing is distributed to the user systems. Consequently, reducing the number and complexity of postbacks as you’re designing browser-enabled forms can substantially boost performance.

    Ten common causes of postbacks

    1. Complex calculations

      A calculation can cause a postback when there is a condition that cannot be evaluated in the browser and requires processing by the server. For example, if a calculation requires data that is not loaded in the DOM, then the browser must send a postback to the server and wait for the result. Another condition that will invoke a postback involves any calculation that is out of the context of the current node. For example, you could create an expression such as .\.\.\my:field1+. When the expression is invoked in the form, because it requires traversing up the tree several levels from the current node, it must be sent to the server for evaluation.

    2. Data adapters

      The function of a data adapter is to make a query connection to an external data source, such as an XML file, a database, a SharePoint list, or a Web service, so that a form can receive and be updated with some data from the data source. If a form invokes a data adapter when the form loads, the browser must wait for the data connection, increasing form load time. If the form invokes a data adapter after the form loads, a postback containing the query request is first sent to the form server, which executes the data connection request on behalf of the browser form, adding additional time to the roundtrip.

    3. Multiple binding: data bound to multiple controls

      Multiple binding happens when one piece of data in the form is bound to two or more controls in the same view. This is usually done so that the same data can be displayed in multiple places. For example, you might design a report with several sections to include a single non-repeating field, such as "Report Date", inside a repeating section so that the same date is displayed in each report section. If you design a form this way, then changing the "Report Date" field in one location will update it everywhere because it is multiply bound. Unfortunately, the cost of this multiple binding might be a roundtrip to the server if the binding is more complex than the browser can resolve. In this case, server analysis is required to reliably identify all the controls bound to the same piece of data. In addition, if something is both multiply bound and out of context, then user edits to form fields will always require roundtrips. Other form actions that will cause roundtrips to the server when there is multiple binding include insertion or removal of repeating tables and repeating or optional sections.

    4. Out-of-context binding

      Out-of-context binding describes a situation where a control inside a repeating or optional section is bound to a node that is in a different part of the XML data source tree, outside the group node that contains the repeating or optional section control. When an out-of-context situation occurs in a form, the correct binding may be too complex to determine within the browser. If either the validity or the kind of action—such as a calculation—cannot be determined in the browser, the out-of context binding will trigger a roundtrip to the server to resolve the binding.

      You are most likely to encounter this problem as you’re designing a form in the InfoPath Designer if you first insert a group or control, and then later decide to move that group or control into an optional section. To avoid creating an out-of-context binding, after you drag and drop the control into the optional section, in the data source pane, drag the node the control is bound to into the group for the new optional section. The group or control will then be bound to the correct context.

    5. View switching

      Multiple views are often used to present a specific view to a specific user audience in a workflow. Multiple views are also commonly used to improve the performance of a form; by careful grouping of related items and limiting the number of controls in each view you can improve the form loading and rendering performance compared to placing everything in a single view. However, each time the view is switched, there is a full postback to send the user’s changes to the server, get the new view, and reload it in the browser. If possible, try to group the items on a view so that any controls that might postback do so when the view is switched. Then only one postback occurs when switching the view. A good example of this is using a button to invoke a query connection that returns data for a list, an operation that requires a postback. If the view is also switched when the button is clicked, you improve the efficiency of the postback. Another benefit of this design is that it makes the view switch a user-invoked action, which improves the user’s perception of the form response. By coordinating the postback of controls in the view with a view switch, you not only improve the responsiveness of the form, but also reduce stress on the server and network by eliminating extra postbacks. When designing your form there is no formula for when to use multiple views, so you will need to balance your use of multiple views with the potential design and performance advantages and costs in your user scenarios.

    6. Conditional formatting

      Conditional formatting is commonly used to hide part of a form from view until some condition is met. However, conditional formatting expressions fire every time the form is rendered whether hidden or not. Additionally, all of the data, calculations, and expressions used by fields that are conditionally hidden are still downloaded and can cause extra performance overhead. Thus if anything else invokes a postback, your form will incur this additional overhead. Similarly, if the conditional formatting requires a postback, then there is a postback each time the form is rendered. Although the primary reason for using conditional formatting has more to do with your form design and presentation, there may also be a slight increase in the responsiveness of the form if it uses conditional formatting. This is possible because it can be slower to render something in the browser than to execute the conditional formatting. However, if you need to substantially limit the presentation, consider using multiple views instead of conditional formatting because multiple views generally perform better.

    7. Digital signatures

      For forms that are filled out in Internet Explorer, signing a form uses an ActiveX control that communicates with the server using out-of-band postbacks. The signature operation involves 3 main steps:

      1. Gather client-specific information to be used by the signature data
      2. Server preprocessing to prepare the stored XML document for signing
      3. Apply the final signature

      Each step causes a postback, the first and the last being relatively expensive. This is because the first postback sends, among other things, the data corresponding to the non-repudiation image to be stored in the signature. The last is a full postback that refreshes the browser with the new signed document that has been prepared on the server.

    8. Business logic event handling

      Normally, when a user changes the values of several controls in the browser form, the JavaScript form logic in the browser can optimize the changes, batching them together to avoid a postback for each change. This reduces the number of postbacks to one. However, this optimization is not possible if the form has code or other logic, such as rules or conditional formatting, that listens to data changes in parts of the XML DOM. For example, if a control is bound to a particular DOM element and a listener is present, changes in that control are immediately communicated to the server and the corresponding event handler invoked. The number of extra postbacks depends not only on the number of event handlers, but also on the XPath they use to listen to DOM events. This is because InfoPath XML events bubble. For example, if some form code has business logic with an event handler that listens to a node close to the root node, there will be relatively more postbacks. This is because any browser change affecting one of the descendants of that node will trigger a postback to the server. Consequently, if your form uses form code or any other construct that involves listening to changes, it is important for performance and scalability that you understand and carefully scope events to reduce unnecessary postbacks and server stress.

    9. Custom hosting pages and external page events

      If you are using advanced form techniques such as developing your own ASP.NET page to host the InfoPath Form control, then there are a couple of things you should be aware of. Submitting to a custom hosting page requires full page postback because the XmlFormView control resides on the server and it involves rebuilding the page controls by ASP.NET. In addition, when submitting the form, before the submit is finalized, data is sent back to the browser with a pending submit action added. This pending submit action must then be sent back to the server in another postback to actually complete the submission. If the page is hosted on a SharePoint site, it also must initialize the SharePoint page infrastructure as well. Also, if an XmlFormView control is hosted on a custom ASPX page and the page listens to events from the control, then every operation triggering an event in the XmlFormView control will require full page postback.

    10. Complex XPaths

      In some advanced form design scenarios, you might build your own complex custom expressions or calculations using the "Edit XPath (advanced)" option. Although most common expressions or calculations can run in the browser, those that require more complex XPaths to evaluate may need to postback to the server. The following complex XPath conditions will cause extra postbacks:

      • More than one possible context for a filter
      • Complex XPath that is not used as a filter
      • XPath where the user input  is not a filter
      • XPath filter or rule that references an element that is not in the current view
      • XPath filter that is position-based
      • XPath with inline functions
      • XPath that includes an unrecognized function
      • XPath that includes an extension function that is not supported by the browser
      • XPath has an inner expression
      • Expressions containing inner nodes


    What’s next?

    In our next article we’ll examine some of the conditions that make postbacks more expensive and that affect the performance and scalability of a server system running InfoPath Forms Services.



  • Microsoft InfoPath 2010

    Workflow user experience in InfoPath


    Microsoft Office SharePoint workflow can be described as a series of tasks implemented with specific business needs to help people manage their project tasks. In Microsoft Office InfoPath 2007, we provide the workflows user experience for InfoPath forms. Additionally, we enable InfoPath business logic to key off workflow properties.

    This article will demonstrate how to enable an InfoPath form to respond to workflow status. Let's explore the following scenario: Nicholas has created an expense report form template and has associated it with a form library with the “Approval” workflow defined. He wants a form to be displayed at different view when the workflow for that form is approved.

    Step 1: Create a expense report document library by publishing a form template

    • Launch Office InfoPath 2007.
    • Create your expense report form template with two views. For example, one is the expense detail view and one is the summary view.
    • Click the File menu | Save to save your template.
    • Publish your form template to a new document library on a SharePoint site. Name the library ‘Expense Report’.

    Note: please leave the form template open as we will come back to customize this template more in later sections.

    Step 2: Switch to SharePoint and add an Approval workflow to the expense report library

    • Navigate to the SharePoint site.
    Note: you will see Expense Report library created on the SharePoint site.
    • Open the Expense Report library.
    • Add an Approval workflow to this Expense Report library via Form Library Settings | Permission and Management | Workflow

    Note: When adding this workflow, you can specify how, when or by whom a workflow to be started and other options regarding how this workflow should work.

    Step 3: Switch back to InfoPath and add a data connection

    This section explains how to add a secondary data connection to query the workflow status of the workflow you added in the previous section. This secondary data connection provides the data that enables business logic in the form to switch views according to the status of the workflow.
    • Switch back to InfoPath. You should still have your expense report form template opened from step 1.
    • Add a Data Connection that receives data from Expense Report library via Tools | Data Connection | receive data from SharePoint library or list.
    • On the page of Select fields, select the check box next to the name of the field that matches the workflow name.
    • Click Include data for the active form only, and then click Next.
    Note: this step is the key point to retrieve current form’s workflow status.

    • Follow all the default options to finish the Data Connection Wizard.

    Step 4: Add a Rule to the form template to switch to a specific view according to current form’s workflow status

    For this example, we want to add business logic to the form that it will switch to summary view when this form’s workflow is approved. This can be achieved by applying an on load Rule to switch view when current form’s workflow status is equal to “Approved” status.

    • Set on load Rule via Tools | Form Options | Open and Save | Rules
    • When setting Condition, you want to select the workflow status field from the secondary data source you added in the previous section in your first dropdown of the condition builder
    • In the second dropdown, choose "is equal to".
    • In the third dropdown, click Type a number, and then type the value that corresponds to the workflow status.

    Status Numeric value
    In progress 2
    Complete 5
    Canceled 15
    Approved 16
    Rejected 17

    In our example, we choose number 16, corresponding to status "Approved".

    Step 5: Republish the form template

    • Click the File menu | Save to save the changes you made to the template.
    • Click the File menu | Publish.
    • Since you republish the form template, the Publishing Wizard will repopulate previous values. Click Nexts -> Publish -> Close to finish the Publish Wizard.

    Now you have successfully designed a workflow driven expense report form template. When a user fills out an expense form from this library, the view of the form will be displayed according to the status of the workflow.

    Emily Ching
    Software Design Engineer in Test

  • Microsoft InfoPath 2010

    UDC File Authoring Tool


    Some time ago, we blogged about the reasons why you'd use UDC files and the anatomy of UDC files. You may be wondering, however, if it's possible to author these files in InfoPath - after all, UDC files are just XML files.

    You're right - this is definitely possible. Attached to this article is a form template that lets you author and edit UDC files. Here are the steps you need to take to make it work:

    1) Download the attached form template, save it to your desktop

    2) Right-click on the downloaded .xsn file, then select Design. Ignore any warnings about the published location.

    3) Go to File | Publish | Network Location, and republish the form template. Then open the form template from its published location.

    Enjoy, and let us know if you have any feedback on the tool.

    Nick Dallett
    Lead Program Manager
    Travis Rhodes
    Software Design Engineer in Test
  • Microsoft InfoPath 2010

    Calling code/script from a Rule


    Rules are a quick way to add dynamic functionality to a form, so a lot of programmers choose to use rules even when they know how to write the code to do the same thing. However, sometimes after writing a complex set of rules they may realize that they need to do something rules doesn’t support, and we know they don’t want to rewrite all their rules in code just to add that one little bit.

    Alas, there’s no rules action type for “Call code”, but there is a roundabout way to call your code anyway.

    Let’s say you have the following function in your form template:

    Function Test(param)
      XDocument.UI.Alert("Param: " & param)
      Test = true
    End Function
    function Test(param) {
      XDocument.UI.Alert("Param: " + param);
      return true;
    Public Function Test(ByVal param As String) As Boolean
      thisXDocument.UI.Alert("Param: " & param)
      Test = True
    End Function
    public boolean Test(string param) {
      thisXDocument.UI.Alert("Param: " + param);
      return true;


    You can call that function from the condition of a rule by using the xdExtension namespace.

    For example, here’s how to call the function from a rule when the form is opened:

    1. Click Form Options on the Tools menu.
    2. On the Open and Save tab, click Rules.
    3. Click Add, name the rule, and then click Set Condition.
    4. Select The expression in the first drop-down list, and then enter: xdExtension:Test(“foo”)
    5. If you want the function to be conditional, then put the condition before the function call with an AND clause. For example, to get if foo>bar, then Test(“foo”), use foo>bar and xdExtension:Test(“foo”). (This is possible because conditions are evaluated using short-circuit boolean evaluation. In other words, they are evaluated one clause at a time, and if the first clause determines the result, then the rest of the conditions are “short circuited” and don’t get executed.)
    6. The Rule dialog box requires at least one action, but if you don’t have any actions to run in that rule, you can click OK if you select the Stop processing rules when this rule finishes checkbox. To avoid actually stop processing rules, make your condition always return false. For example: xdExtension:Test(“foo”) and false (“false” here is actually looking for the node named “false” which doesn’t exist, so returns the empty set, which is translated to false(). You could just as easily use “foobar” or anything else.)

    Finally, extract your form files and add the following attribute to the manifest.xsf file’s xDocumentClass element:


  • Microsoft InfoPath 2010

    Implementing Roles in Browser Forms


    What are Roles? Without going much in detail, InfoPath roles is a functionality where you can define user tags like "Sales", "Management" and utilize them in your form logic. This enables some very interesting scenarios in the forms space. For a detailed discussion on this topic, take a look at this MSDN lab. If you have worked with InfoPath 2003, you would notice that Roles have not changed much in 2007, and that they are not supported by InfoPath Forms Services. My focus will be in how we can enable role-related scenarios in browser forms.

    For the purpose of this article, lets borrow the scenario from the lab. - "The management team at Contoso Corporation reviews each of the Sales Report filled out by sales representatives. Because the management team is interested only in sales deals that exceed a certain amount of money, your department is asked to add an additional view to the sales form that shows only those deals"


    STEP 1: Find a way to store role-related data

    You can store information about which users belong to which grounps in an XML file, included as resource as a part of the XSN. Here's one way to organize this XML file:


    <?xml version="1.0" encoding="utf-8"?>

    Create a data source pointing to this resource file and use this data source to make decisions in step 2.

    Variation: Roles and Users relationship might be stored in a database (say HR system). You would then create a secondary data source connecting to your HR System instead of the XML file mentioned above; everything else stays the same.

    STEP 2: Determine the role of the current user

    1. Add hidden fields to the main data source of your form. These will store:

    • Active Directory username (alias) of the currently logged on (let's call the field CurrentUser)
    • Role of the current user, as determined by our form logic (let's call the field CurrentRole)

    2. Set the detault value of CurrentUser to the username() function.

    3. Set "CurrentRole" value to

    name[username = CurrentUser]


    STEP 3: Use rules and CurrentRole

    To accomplish our scenario, we will create two views: one for "Sales", and one for "Management". Using Rules, you can switch to the appropriate view on load of the form:

    1. With the form template in design mode, on the Tools menu, click Form Options.
    2. Click the Open and Save tab, and then click Rules, and the following two rules:

    • If CurrentRole = "Sales", switch the view to the Sales view.
    • If CurrentRole = "Management", switch the view to the Management view.

    And that's it! You can use CurrentRole the same way you'd have used Roles in the InfoPath smart client. Note that this trick works on the smart client, too - so if you want to create a roles-based InfoPath application, this method will help.

    Pradeep Rasam
    Program Manager

  • Microsoft InfoPath 2010

    Use Visual Studio to create InfoPath forms… without code

    Although the primary purpose of Visual Studio 2005 Tools for Office (InfoPath 2007 Support) is to add C# and Visual Basic code to your InfoPath form template, you can still take advantage of hosting InfoPath inside Visual Studio to design forms that don't have any code.
    When you create a new InfoPath form template project in Visual Studio, by default, it will be created with code enabled.  To obtain a form without code, you need to explicitly remove the code from the form by using the remove code button in the programming tab of the form options dialog.
    After clicking on this button, you might be confused to see that the code file is still present in the project.  Don’t worry about this.  When you build the project, the hosted designer will not add the output assemblies to the form template.
    How it works
    After a new project is created, the “enabled” attribute of the “managedCode” element in the manifest.xsf defaults to “yes”.  Clicking the remove code button sets this attribute to “no”.
    <xsf2:managedCode … enabled="no"></xsf2:managedCode>
    This attribute is set back to “yes” when you insert an event handler using the hosted InfoPath designer.
    After a success build, the output assemblies will only be included with the form template when this attribute is set to yes.
    - Gary
    Software Development Engineer
  • Microsoft InfoPath 2010

    Transforming InfoPath Rich Text to Word


    This article applies to InfoPath 2003 and Word 2003.


    InfoPath is great for capturing structured data. A common scenario is that you need to output that data in a Word document. It is quite easy to create an XSLT transformation that will take the XML generated by InfoPath as input and generate WordprocessingML tags. For example, to output the value of the EmployeeName form field in a word document’s paragraph you would use the following XSLT fragment:

         <xsl:value-of select=”my:EmployeeName”/>

    Most mappings will be quite similar, in that they end up in a <w:t> tag, which Word uses to contain, well euh… text. There is one exception to this, namely when you use rich text fields in your form. A rich text field can contain formatted text, images, hyperlinks, tables, etcetera and although the XHTML format that is used to represent the contents is similar to WordprocessingML, there are important differences. This article provides a reusable solution for dealing with those differences.

    Downloads: XSLT transformation source code and sample input files are all bundled in the attached archive.


    To illustrate the capabilities of a rich text field I created the form below, which contains a single rich text field. I created an instance of it with some sample formatted content:

    The contents of the field itself is structured using the XHTML standard, that looks like this:

    <div xmlns="">This is an example of a rich text control that contains various formatted elements such as <strong>bold </strong>and <em>italic </em>text, aligned text with <font color="#0000ff">foreground </font>and <font style="BACKGROUND-COLOR: #3366ff">background </font>colors, <font style="BACKGROUND-COLOR: #ffff00"><strong>bulleted</strong></font> and <font style="BACKGROUND-COLOR: #0000ff" color="#ffff00">numbered </font>lists, a table and an image.</div>

    Should you try to insert this as such in a <w:t> tag, you would end up with an invalid Word document. You have to take each individual XHTML tag and transform it to its WordprocessingML counterpart. For some tags (strong, font, …) this is quite straightforward, but for others this can be quite a challenge.

    What you will find in the download accompanying this article, is an XSLT template that you can include as is in your own XSLT stylesheets and that will result in a visually equivalent word document. The result of transforming the above form to word using this template looks like this:

    Beware that this is a work in progress. The template is suitable for most basic formatting (things you hand-type in the form), but will most probably fail when you cut/paste content from the web with heavily nested table formatting. If you have that requirement, you’ll have to resort to coding techniques rather than transformation.

    The input files

    The download contains a number of xml documents generated with Infopath. To test these with the transformation, right-click the file and choose Open With… Word. In the XML task pane, browse to the “BASIC IP_To_Word.xslt” to transform.

    The transformation file

    The first part of the “BASIC IP_To_Word.xslt” file is simply a blank word document saved as xml and then turned into a stylesheet. This can be done in a few easy steps:

    1. Wrap the entire document in <xsl:stylesheet version=”1.0”> tags
    2. Remove the <?mso-application …> processing instruction
    3. Move all the namespace definitions in the wordDocument tag to the stylesheet tag
    4. Add the xsl namespace as xmlns:xsl=””
    5. Add the namespace of the source xml file, for example: xmlns:ns0=”http://YourCompany/YourXMLRootNode”
    6. Move the closing </w:body> and <w:wordDocument> from the end to right after the <w:body> opening tag
    7. Wrap the <w:wordDocument> node in an <xsl:template match=”/”> node
    8. Right before the <w:wordDocument> node, add
      <xsl:processing-instruction name="mso-application">
    9. In the <w:body> node, add <xsl:apply-templates select=”/ns0:YourXMLRootNode”/>
    10. Wrap the remainder of the body in a node <xsl:template match=”ns0:YourXMLRootNode”/>
    11. Add <xsl:value-of select=”ns0:YourNode”/> instructions where needed
    12. If you have repeating nodes, you can add these with an <xsl:for-each select=”...”> construct

    The interesting stuff is where the rich text field IPRT is passed to a template named “infopath rich text”. Everything below it can be copied to your own stylesheet. Then you can use the following construct to render any rich text field anywhere in the word document:

    <xsl:template match=”my:YourFieldHere”>
          <xsl:call-template name=”infopath-rich-text”/>

    You can also add the following parameters to the call template instruction:

    pPr_Default: A list of paragraph formatting properties that need to be set on each paragraph transformed from the rich text

    rPr_Default: A list of character formatting properties that need to be applied on all the text (for example the default font)

    Stephane Bouillon
    Senior Consultant
    Microsoft Consulting Services

    Thanks goes to David Gerhardt for his articles.

  • Microsoft InfoPath 2010

    Upgrading InfoPath 2007 forms with Person/Group Pickers to InfoPath 2010


    Hi, this is Frank Mueller again and this is the second of two posts that I’ve written about the InfoPath 2010 Person / Group picker control. InfoPath 2007 form templates containing the Person/Group Picker control (formerly named Contact Selector) will continue to work in InfoPath 2010 the same way they used to as long as the form template remains in the InfoPath 2007 Form Template format. However, if you wish to upgrade your form template to InfoPath 2010 to take advantage of newly added functionality for the control (see this blog post for more details) or other exciting new features, you will have to perform the steps outlined in this post in order to use the Person/Group Picker.

    If you follow the steps outlined in this blog post to change your form template, you are changing the data schema of the form template. This means you will not be able to view any previously filled out forms with the new form template. In order to avoid data loss, you should create a new InfoPath 2010 version of your form template and publish it to a different location. This way you can continue to view previously filled out forms with the InfoPath 2007 version of your form template.

    Saving the form template in InfoPath 2010 form template format

    1. Click the File button and select Save As
    2. In the Save As dialog select the corresponding InfoPath 2010 Web Browser or Filler Form Template in the Save as type dropdown.
    3. Change the file name to be something different so that you don’t overwrite your existing form template
    4. Click Save

    Removing existing versions of the control from the form

    After the form template is saved in the new format, you will notice that each Person/Group Picker in your view will show the following error message when you hover your mouse cursor over it.

    Incompatibility error visual

    Also the Design Checker task pane appears, indicating that the version of the Person/Group Pickers in the view is not compatible with InfoPath 2010. For each Person/Group Picker in all views, do the following:

    1. Select the Person/Group Picker control in the view
    2. Notice that the XML node tree that the control is bound to will be highlighted in the Fields task pane (if the Fields task pane is not visible, click Show Fields on the Data tab in the Ribbon).
    3. Delete the highlighted XML node tree by deleting the root node in the Fields task pane (Right-click the node, and select Delete from the context menu)                                                   Fields Task pane
    4. Select the Person/Group Picker control in the view and delete it
    5. Use the Controls Gallery on the Home tab to insert a new Person/Group Picker at the position in the view where you just deleted the control
    6. Right-click the newly inserted control in the view and select Person/Group Picker Properties from the context menu
    7. In the Person/Group Picker Properties dialog select the SharePoint Server tab
    8. Type in the URL of the SharePoint site (If you don’t know the SharePoint site that the control used to connect to, please follow the optional steps at the end of this blog post.) Control Properties
    9. Click OK to close the dialog


    Testing the Person / Group Picker

    Preview the form in InfoPath Designer or publish the form to a SharePoint site (be sure to publish to a different location in order to be able to view previously filled out forms) and view the form, enter a name or logon alias, click the “Check Names” button and resolve the name! Alternatively you can click the “Address book” button to perform a search if you do not know the complete name of the user.

    Configuring advanced SharePoint list control properties (optional)

    To configure advanced control properties  that are new in InfoPath 2010, such as limiting the entities the control can pick, as well as requiring the control to contain data before the form can be submitted, follow the steps in this blog post.

    Determining the SharePoint site URL (optional)

    If you added the control to your InfoPath 2007 form template following the steps outlined in this blog post, you will have created a data connection called Context, which specifies the SharePoint site the Person/Group Picker should connect to. Follow these steps to recover the data connection XML file and obtain the URL of SharePoint site:

    1. Start InfoPath Designer 2010 and open your InfoPath 2007 form template
    2. Click the Data tab and select Resource Files Data Tab - Resource Files
    3. In the Resource Files dialog select Context and click on the Export button to save the data connection XML to a location on your hard drive.
    4. Open the XML file in a text editor (e.g., notepad)
    5. Write down the siteUrl to configure the Person/Group Pickers

    Frank Mueller

    InfoPath Developer

  • Microsoft InfoPath 2010

    Collapsible Sections


    Collapsible Sections


    Mark asks:


    How do I create a collapsible section? That is, a section that can show/hide child controls, whether they are required or not. I can't use an optional section, because it requires binding.


    The easiest way to do this is to this is using Conditional Formatting. Select the Section control, then pick Format | Conditional Formatting.... Add a rule where the formatting is “Hide this control”.


    Adding conditional visibility to a section


    We often call this “conditional visibility.” Like everything in InfoPath, the view state is driven entirely by the data, so you need something in your data which maps to the expand/collapse state. One common approach is to add an attribute field to the group element the section is bound to. It shows up in your data when saved, and the expand/collapse state is saved when users save the form.


    Designing a collapsible section


    Bind a checkbox to the attribute, and you now have UI which lets the user control the state. If you prefer a button, you can create a rule which sets the value of the attribute; use two buttons with more conditional visibility rules to swap the label (e.g. between a + and a – to look like a TreeView). You can also write code which modifies the value of the attribute, and the section will show or hide.


  • Microsoft InfoPath 2010

    Calculating new, default date and time values


    Similar to performing elapsed time calculations, creating a new date or time value based on a previous value used to require code – not anymore! With InfoPath 2007 you can use the new “addDays()” and “addSeconds()” functions to calculate a new date or time based on a previous value.

    To illustrate this, think of a daily task planner: you enter a start time for the first task and specify a duration time and interval. The starting value for the next task should be the prior tasks’ starting time plus the prior tasks’ duration. Using the addDays and addSeconds functions will allow you to specify the new starting date and time based on a duration specified in days, hours, minutes or seconds without writing any code!

    The following steps will create a sample Daily Task Planner to demonstrate how to implement these functions. A sample form template that implements this functionality is attached; make sure to save it locally before running it.

    1. Create the data structure

    a. Create a new browser-compatible form template
    b. Add a repeating group named: gpTasks to the myFields collection
    c. Add the following nodes to gpTasks:

    Name Data Type
    StartDateTime Date and Time (dateTime)
    TaskDesc Text (string)
    Duration Decimal (double)
    Interval Text (string)

    d. Add the following node to the myFields collection:

    Name Data Type
    NextStartTimeValue Date and Time (dateTime)

    Note: The “NextStartTimeValue” field is needed because using XPATH functions such as “preceding-sibling”, which could be used to get the prior elements values, are not supported in browser forms.


    2. Create the View

    a. Add gpTasks to the View as a Repeating Table
    b. Change the Interval Text Box to a Dropdown List Box
    c. Add the following entries to the Interval Dropdown list box:
    d. Add a new column to the right of the StartDateTime field and re-bind the newly created field to StartDateTime (this field will be used to display just the time value)
    e. Change the format of this new field to: *9:46 AM


    3. Add the expressions

    a. Set a default value for the StartDateTime field to the current date and time when the form is first launched (note - we don’t want the current date and time to be entered once we have rows of data:)
          Add a Rule to the Open event of the form
          Add the following Conditions to the Rule:
              - The “count” of gpTasks = 1 (i.e. count(my:gpTasks) = 1)
              - The NextStartTimeValue field is blank
          Add an Action to set the StartDateTime field to the “now()” function

    b. Add a “Set a field’s value” Rule to the Interval field to set the NextStartTimeValue field, with a condition that the rule should only fire if the Duration field is not blank. In the Value property for this Rule, we need to check the Duration and what Interval was selected so we can populate the NextStartTimeValue field with the correct date and time. Let’s take a look at how these expressions are created. (This information is based on using the advanced default value logic documented in this blog post)

    You can use the “concat”, “substring” and “string-length” functions to create an “if/else” type of statement. First, we want to see if the selected Interval was “Days” – to do this, we use the “contains” function along with the substring function.

    substring(xdDate:addDays(../my:StartDateTime, ../my:Duration), 1, contains(../my:Interval, "Days") * string-length(xdDate:addDays(../my:StartDateTime, ../my:Duration))

    You would actually interpret this expression right-to-left in this manner: “If the Interval field contains “Days” then use the addDays function to add the value in the Duration field to the value in the StartDateTime field.”

    We use a similar expression to check for the value of “Hours” in the Interval field and then use the “addSeconds” function to add the appropriate number of seconds:

    substring(xdDate:addSeconds(../my:StartDateTime, ../my:Duration * 60 * 60), 1, contains(../my:Interval, "Hours") * string-length(xdDate:addSeconds(../my:StartDateTime, ../my:Duration * 60 * 60))

    Lastly, if the Interval field does not contain Days or Hours then it must contain “Minutes”:

    substring(xdDate:addSeconds(../my:StartDateTime, ../my:Duration * 60), 1, contains(../my:Interval, "Minutes") * string-length(xdDate:addSeconds(../my:StartDateTime, ../my:Duration * 60))

    We then use the “concat” function to bring all of these expressions together to set the Value property:

    concat(substring(xdDate:addDays(../my:StartDateTime, ../my:Duration), 1, contains(../my:Interval, "Days") * string-length(xdDate:addDays(../my:StartDateTime, ../my:Duration))), substring(xdDate:addSeconds(../my:StartDateTime, ../my:Duration * 60 * 60), 1, contains(../my:Interval, "Hours") * string-length(xdDate:addSeconds(../my:StartDateTime, ../my:Duration * 60 * 60))), substring(xdDate:addSeconds(../my:StartDateTime, ../my:Duration * 60), 1, contains(../my:Interval, "Minutes") * string-length(xdDate:addSeconds(../my:StartDateTime, ../my:Duration * 60))))

    c. Add a “Set a field’s value” Rule to the Duration field to also set the NextStartTimeValue field – again, add a condition where we only want this rule to fire if the Interval field is not blank. Use the same expression as above to set the Value property:

    concat(substring(xdDate:addDays(../my:StartDateTime, ../my:Duration), 1, contains(../my:Interval, "Days") * string-length(xdDate:addDays(../my:StartDateTime, ../my:Duration))), substring(xdDate:addSeconds(../my:StartDateTime, ../my:Duration * 60 * 60), 1, contains(../my:Interval, "Hours") * string-length(xdDate:addSeconds(../my:StartDateTime, ../my:Duration * 60 * 60))), substring(xdDate:addSeconds(../my:StartDateTime, ../my:Duration * 60), 1, contains(../my:Interval, "Minutes") * string-length(xdDate:addSeconds(../my:StartDateTime, ../my:Duration * 60))))

    d. Add a “Set a field’s value” Rule to the Repeating Table to set the StartDateTime field to the value stored in the NextStartTimeValue field (this is what will set the Start Date and Time fields when a new row is added to the table)


    4. Test!

    Here is a sample completed Task Planner:

    NOTE: Because this is a “no code” solution, if you modify an existing start date or time there is no way to enumerate the balance of the nodes to reflect this change. A feature such as this would require code.

    Scott Heim
    Support Engineer

Page 3 of 12 (298 items) 12345»