Microsoft InfoPath 2010
The official blog of the Microsoft InfoPath team

June, 2006

  • Microsoft InfoPath 2010

    Publish faster to even more places with InfoPath 2007

    When designing a form template, publish is an important step to make the form available for end users of the form. In InfoPath 2007, we have made some modifications and improvements to the publish process. This article is intended to highlight some of the key changes you will encounter in the publishing wizard.
    Let us start off with a snapshot of the page in the wizard which helps you decide where to publish.
    Here is the second page in the wizard when you invoke File/Publish in InfoPath 2003.
    Here is the first page in the wizard when you invoke File/Publish in InfoPath 2007.
    Here are some key differences that you can notice:
    • Windows SharePoint Services server is now the default option and it can be used to publish to SharePoint server with or without InfoPath Forms Services. This option itself has several new features worth a blog post of its own.
    • Shared folder and web server options have been collapsed into one, namely, network location. This option includes the functionality of both shared folder and web server.
    • Email has been added to allow sharing templates via email. This functionality used to be available previously under File menu as "Send form as attachment". This option can be used to generate InfoPath email forms integrated with Outlook 2007.
    • Installable form template option has been added. This makes it really easy to create installable solutions which you may need to do if you are form's security setting is fully trusted.
    • A new branch to publish a Document Information Panel template on a SharePoint site has been added. However this option will show up only when it is relevant (i.e. you are customizing a content type in SharePoint).
    Work on it here, publish it there
    Another important difference is the concept of "working/developer copy" vs. "published copy". In InfoPath 2003, when you complete the publish wizard, your working solution will be the same as the published copy. In other words, any changes you are making from then on is on the published copy which may not be something you want to do. In InfoPath 2007, when you complete the publish wizard, your working solution is still the original copy that you were working with and subsequent changes to the solution will not affect the published copy unless you chose to publish those additional changes.
    Publish once, publish again
    We have also made it really easy to make updates to your published copy. Once you have successfully published once, the next time you go through the wizard, it will remember your previous information and automatically populate them for you. This makes it really easy to go through the wizard for subsequent publishing without having to re-enter various information.
    Hope you have a great experience publishing form templates using InfoPath 2007.
    Senior Development Lead
  • Microsoft InfoPath 2010

    Introducing Horizontal Repeating Tables

    InfoPath 2007 adds horizontal repeating table to the control toolbox for when you want data to be entered or displayed in a structured, tabular format, and when you want users to be able to add additional columns instead of rows.
    For example, you might use a horizontal repeating table to collect sales data for each quarter:
    Making it wrap
    When designing your form template, horizontal repeating table looks like a composite control -- it’s made from a horizontal repeating section and layout tables (I'll cover horizontal repeating section in my next post). Horizontal repeating table can be configured to wrap or scroll. By default, it will wrap to the next line, to provide a better printing experience.
    You can change the behavior of the control by resizing the layout tables; for example, to change the wrapping point, resize the rightmost border of the layout table:
    This will allow only two instances of the repeating column to fit on one line; the next two will go to the next line, and so forth:
    Making it scroll
    You may want to set an upper bound on the amount of real estate that a horizontal repeating table can take up; in that case, you need to make the control scroll. User experience will then be similar to the following:
    To achieve such behavior, you need to make the following modifications to your form template:
    1. Encapsulate the repeating section component of the horizontal repeating table in a scrolling region.
    2. Set the properties on the scrolling region:
      • Show horizontal scroll bars: always
      • Show vertical scroll bars: never
      • Wrap text: unset
      • Margins: all zero
      • Padding: all zero
      • Size: appropriate height and width
      • Borders: no borders
    3. Resize the rightmost border of the layout table that contains the horizontal repeating table to match the border of the scrolling region.
    When you’re done, your form template will look similar to the following in Design mode:
    Scrolling is often desirable for electronic forms, but is not ideal for printing. If you want to achieve both, you need to use scrolling in the view that users will see when filling out the form and wrapping in an associated printable view.
    Data binding of a horizontal repeating table is identical to that of a regular repeating table or section.  Horizontal repeating tables support conditional formatting, data validation, rules, calculations, other InfoPath data features that a regular repeating tables support.
    Note that horizontal repeating tables are only supported in InfoPath 2007 client.
    - Alex Weinstein
    Program Manager
  • Microsoft InfoPath 2010

    Advanced server-side authentication for data connections, part 2


    In the first part of this series I introduced the concepts involved in three tier authentication. Now let's drill into the details and work with some code.


    Using Office Single Sign-on  with individual mapping

    An Office Single Sign-on (SSO) application definition, can be set up in one of three ways:  individual, group, or group using restricted credentials.  An InfoPath form published to the server can use either of the first two.  However, in order to use individual credentials, the SSO database must contain a separate username and password for each user who connects to the form.  A typical server application would check whether the connecting user had credentials in the database, and redirect to a credentials management page when appropriate to allow the user to enter their credentials.  While InfoPath Forms Services does not do this generically for forms that use SSO, it’s possible to implement a solution for an individual form or a set of forms the same way an Office Server application would, by using the Pluggable SSO API.
    The general approach is to have users link to an ASP.NET page rather than directly to the form.  The ASP.NET page attempts to get the user’s credentials from the SSO database, and based on the result either redirects to the form or to a credential management page  which allows the user to input their credentials.
    Enough talk.  Let’s get our hands dirty.
    My code assumes that you have defined an SSO application definition called MyApp and that the application is set up to use individual credentials.  I also assume that that have an administrator-approved form template called myform.xsn activated on the site collection, and that the form uses one or more data connections that reference the MyApp application.
    In order to use SSO to make the data connection, you must be using data connection settings in a UDC file on the server.  To add the reference to the MyApp app definition, you add an Authentication element to the UDC file.  The authentication element must be the last subelement of the ConnectionInfo element, and it looks like this:
      <udc:SSO AppId="MyApp" CredentialType="NTLM"></udc:SSO>
    To create the redirector page, the first thing is to add a new ASP.NET page to the root site of your SharePoint server.  Find the home directory of your root site by opening up Internet Services Manager and checking the Home Directory page of the properties page for the web application.  Open this web in Visual Studio and add a new ASP.NET page.  In the properties  for the page, enable session state.  Finally, add a reference to the Microsoft.SharePoint.Portal.SingleSignon namespace.
    Once this is done, the new page should look like this:
    <%@ Page Language="C#" AutoEventWireup="true" CodeFile="SingleSignonRedirector.aspx.cs" Inherits="SingleSignonRedirector" EnableSessionState="True" %>
    <%@ Import Namespace="Microsoft.SharePoint.Portal.SingleSignon" %>
    Open the code file for the page, and add a using statement for the SingleSignon namespace
    using Microsoft.SharePoint.Portal.SingleSignon;
    The code itself is relatively straightforward.  Start by using the pluggable API to get a reference to the installed SSO provider.
    ISsoProvider provider = SsoProviderFactory.GetSsoProvider();
    (this call will fail if no provider is installed, or if the Single Signon service is not running)
    Your page will run under the credentials of the user attempting to access the form, so when you call GetCredentials, SSO will return a credential for that user, or throw SingleSignonCredsNotFoundException if the credential does not exist.
       SsoCredentials credentials = provider.GetCredentials("MyApp");
    catch (SingleSignonCredsNotFoundException)
    In the event that the credentials are not found, you can get the URL of the credentials management page for the installed provider.
    Uri CredentialsManagementUrl = provider.GetCredentialManagementURL("MyApp");
    Now, at this point you could simply redirect to the credentials management URL.  However, you would miss part of the magic of the credentials management page.  The credentials management page supplied with the Office single Sign-on provider will redirect back to the referring page once the user has entered valid credentials.  I chose to handle this by presenting a link to the user to allow them to click through to the credentials management page.
    Response.Write("<P>Before you can access this form, you must enter credentials to access backend data.</P>");
    Response.Write("<P><A href=\"" + CredentialsManagementUrl.ToString() + "\">Click here to enter your credentials</A></P>");
    An alternate approach could be to add the HTTP referer header to the response before performing a redirect.  Either way, once the user has entered their credentials, the redirector page will be called again.  This time the GetCredentials call will succeed, and the page will redirect on to the form.
    Here’s the complete code-behind for the page:
    using System;
    using System.Data;
    using System.Configuration;
    using System.Collections;
    using System.Web;
    using System.Web.Security;
    using System.Web.UI;
    using System.Web.UI.WebControls;
    using System.Web.UI.WebControls.WebParts;
    using System.Web.UI.HtmlControls;
    using Microsoft.SharePoint.Portal.SingleSignon;
    public partial class SingleSignonRedirector : System.Web.UI.Page
        protected void Page_Load(object sender, EventArgs e)
            ISsoProvider provider = SsoProviderFactory.GetSsoProvider();
                SsoCredentials credentials = provider.GetCredentials("MyApp");
            catch (SingleSignonCredsNotFoundException)
                Uri CredentialsManagementUrl = provider.GetCredentialManagementURL("MyApp");
                Response.Write("<P>Before you can access this form, you must enter credentials to access backend data.</P>");
                Response.Write("<P><A href=\"" + CredentialsManagementUrl.ToString() + "\">Click here to enter your credentials</A></P>");
            catch (Exception ex)
                Response.Write("<P>Single Sign-on returned an error:  " + ex.Message + "</P>");
            // Good to go - on to the form
    Response.Redirect( "http://myserver/formservertemplates/myform.xsn?openin=browser" );
    Getting jiggy with it
    For a real-world application, there are a few more things I might do to this page to round out the implementation.  Depending on the needs of the specific application, one or more of the following might apply:
    • Loop through multiple Application IDs to allow the user to enter credentials for each
    • Attempt to log on the user using the SSO credentials to verify that the credentials are valid and have not expired
    • Use this code in a page which hosts the form in question using the XmlformView control
    • Create a generic page which takes the URL to the form and the Application ID as query parameters
    With a little bit of ingenuity, you can use this approach to create a seamless end-to-end experience to satisfy any scenario.
    In my next and final post in this series, I'll talk about how to use a web service proxy for authentication. Stay tuned!
    - Nick
    Program Manager
  • Microsoft InfoPath 2010

    Add C# or Visual Basic to your existing form using VSTO

    Have you ever created an InfoPath form to later discover that you have to write code in order to accomplish something you need?
    If so, you have one of two options:
    You can use VSTA to add managed code to your form.  It is included in the Office package, but it is turn off by default.  You must go the Add/Remove Programs and customize Office to install it.
    -- OR --
    You can use VSTO to add managed code to your form which is what this blog entry is about.
    When you create an InfoPath Form Template using Visual Studio 2005, you start with the Design a Form dialog.  On the left you’ll see:
    Choosing one of these options will allow you to create a project using an existing form template.  For example, if you wanted to use a form template from a SharePoint site, you would choose the second option.  You can also choose the last option to import an Excel workbook or a Word document as your form template.
    If you've selected an existing form template, you will get a message:
    If you've selected a form template that already had code behind it, the existing code will be removed from the new form template as well.
    VSTO will now create a project based on the form you've selected and you're ready to add code!
    - Gary
    Software Development Engineer
  • Microsoft InfoPath 2010

    Open your rolodex from InfoPath using the Contact Selector

    Speaking of Outlook integration, Microsoft Office 2007 includes a new control that enables you to choose one or more e-mail address from the address book.
    You can add this control to InfoPath’s list of custom controls by using the Add or Remove Custom Controls wizard like you would for any other ActiveX control.  When registering the control, you can choose most of the default options. However, you must choose "Field or Group (any data type)" in the "Specify Data Type Options" page of the wizard. If you don't choose this binding type, the control will be disabled when you try to fill out the form.
    When you insert this control in a form template, it looks like this:
    When you insert this control in design mode, only a group node is added to the data source. You must manually add additional fields in order for this control to work correctly. To determine the final data structure should be, open the properties dialog for the control and click on the "Items" tab. This tab lists the schema structure that is required.
    As I mentioned, you must manually add these fields to the data source. This can be quite painful if you want to use the control in a lot of form templates. However, here’s a little trick.  You can create a Template Part that contains only the data structure and no controls in the view. Now, when you need to use the Contact Selector, first insert the Template Part to create the data structure.  (This will insert an empty Section control into the view which you can then remove.)  Then, go to the data source, right-click on the group node that was inserted, and select Contact Selector from the More menu.
    Template Parts don't support ActiveX controls so you can't insert the Contact Selector into the template part which would make this even easier. However, using this empty template part that contains only the data structure is still easier than creating the structure from scratch each time.
    Scott Roberts
    Senior Development Lead
  • Microsoft InfoPath 2010

    Accessing InfoPath forms from Outlook

    We have made significant investment in Office 2007 to better integrate InfoPath with Outlook. To that effect we have made it really ease to use InfoPath forms from within Outlook. When you email InfoPath forms from InfoPath 2007(using File/Send To Mail Recipient or Email submit adapter), you will now have an enriched experience when viewing these InfoPath e-mail forms. In this post, I highlight just one of the several features that we have added to Outlook 2007.
    Let us say, while you are working on your emails, you remember that you need to fill out a (InfoPath) form. You don't need to switch from Outlook any more. You can access the InfoPath dashboard from within Outlook by clicking on the "Choose InfoPath Form" option under "New" menu as shown below.
    This will bring up a condensed version of the regular InfoPath "Fill out a form" dialog. Most of the editor functionality is available in this condensed version. If you need to switch to InfoPath design mode (or use any additional functionality not exposed in this condensed version) then you can click on "Open InfoPath" button at the bottom left of this dashboard to launch InfoPath application:
    To learn more about InfoPath Outlook Integration I encourage you to visit Tudor's blog titled "Using InfoPath e-mail forms" at 
    Hope you found this article useful and are interested in exploring the numerous features that Tudor talks about in his blog.
    Lead Software Design Engineer
  • Microsoft InfoPath 2010

    Advanced server-side authentication for data connections, part 1

    To tier three... and beyond!
    Real-world enterprise applications are seldom restricted to a single server.  Anyone who has created a nontrivial multi-tier application in a Windows environment has had to work around a fundamental limitation in NTLM authentication:  namely, that NTLM authentication tokens cannot be delegated past the second tier.
    Could you bounce off the wall and say that again?
    OK, in simpler terms:
    When you log onto your workstation, you present windows with primary evidence of your identity in the form of a username and a secret – usually a password, but sometimes a certificate or a biometric identifier such as a fingerprint.
    When you connect to a web application in a browser, your workstation contacts the web server and tells the server who you are.  The server trusts the workstation because it knows that the workstation has primary evidence of your identity, but the server has only second-hand evidence.
    When the web server connects to the data server, it passes your authentication token, but the data server won't accept it because the chain of trust is too long.  The data server has only third-hand evidence of your identity.  Bzzzzzzzzzt – thank you for playing!
    With InfoPath 2003, you never had to worry about these issues when designing your form.  You ran InfoPath on tier 1, and the database, Web service, or SharePoint site on tier 2 trusted your computer's first-hand evidence.  Now that you are designing forms that run in a web browser, you'll need to think about tier 3.
    There are a number of ways of dealing with tier 3 and beyond in forms services.  I'll start by briefly describing three simple techniques for noncritical applications, then I'll move on to enterprise-quality solutions, culminating in two technologies that are specific to Microsoft Office SharePoint Server.
    Keep in mind that for form templates that are not admin-approved and fully trusted, the connection settings need to be stored in a Universal Data Connection (UDC) file in a Data Connection Library in order to make a connection to another domain.
    Anonymous connections
    For trivial data connections, such as looking up a list of states to populate a drop-down list, you can simply allow anonymous users to access your data.  Removing the need to authorize the user means that it's no longer a problem that your identity can't be verified on tier 3.
    HTTP Basic Authentication
    In Basic authentication (or digest, which is a slightly more secure version of the same protocol), your browser prompts you to enter your username and a password, which are then passed in cleartext (or in digest form) to the web server.  The web server now has primary evidence of your identity, so the data server can trust it to tell it who you are.  You can set up IIS on your SharePoint server to use Basic authentication instead of Windows Integrated authentication.  While this is a quick way to do an end run around the tier 3 problem, it presents an awkward user experience on the intranet.   This is better suited to the extranet, where getting prompted for additional credentials is a more familiar experience. Don't forget to set up SSL so that your users' credentials are encrypted on the wire.  Otherwise, anybody monitoring your server traffic can read the passwords as they pass by.
    Embedded SQL credentials
    It's common practice in web applications to connect to a database using a SQL username and password embedded in the connection string.  Since this requires putting a password in cleartext in a configuration file, it is not considered a secure method of authentication.  By default, user form templates on the server are not allowed to use embedded SQL credentials.
    Unlike NTLM authentication, a Kerberos authentication token, called a "ticket", can be independently verified at any point in an n-tier system and thus can be delegated indefinitely within the window of time that the ticket is valid.  For enterprises where Windows XP or better is the standard desktop and Windows Server 2003 is the standard server, Kerberos can replace NTLM as the standard authentication method in Active Directory.  This is the preferred method of overcoming the 2-tier restriction on token delegation when available.
    Constrained Delegation
    In constrained delegation, two services on two servers can be configured to allow a specific set of user accounts to be delegated from one service to the other without requiring independent verification of a password.  While this is considered a secure option, it is notoriously difficult to set up and maintain.
    Office Single Sign-on
    Office Single Sign-on (SSO) is a service on Microsoft Office SharePoint Server which was created to help applications on the server overcome authentication delegation issues.  At its heart, SSO is simply a database which stores encrypted username and password pairs.  An application running on the server can obtain a username and password associated with a known SSO application definition and can then use those credentials to log on to Windows and make a trusted connection to a data source. A form running on the server can use SSO to connect to external data by specifying an SSO application ID in the UDC file containing the connection settings.
    Web service proxy
    InfoPath Forms Services includes functionality to forward Web service requests from a form.  The web service request is made using the identity associated with the SharePoint web application.  In order to allow the web service to authorize access to the external data, the user's Windows username is passed in the SOAP header using a WS-
    Security UsernameToken
    In my next two installments, I'll describe in more detail how to use Office Single Sign-on and the Web service proxy to connect to enterprise data from your browser-enabled forms.
    In my next post we'll cover Single Sign On and write some code.
    - Nick
    Program Manager
  • Microsoft InfoPath 2010

    Improvements to Share Point integration - Property demotion

    One of the new features in InfoPath 2007 when publishing to a SharePoint 2007 server is the ability to turn on property demotion.
    Property demotion is the ability to be able to modify fields that show up in SharePoint document libraries and cause those fields to be automatically updated in the underlying document (in this case InfoPath form).
    Where would you use demotion?
    Imagine you have a document library where you save your company assets as InfoPath forms. Let us say one of the fields in the library, is the current owner of this asset. When you need to bulk assign a bunch of assets from one person to another, wouldn't it be really easy if you can just update this field in a data grid view instead of opening each and every asset form and having to update it.
    Let us see how you can enable property demotion
    When you go through the publish wizard (File/Publish) pages for publishing to SharePoint, InfoPath will detect if the server is 2007 and if it finds that to be true, you will now be able to turn on property demotion for a field by selecting the check box as shown in the image below.
    Note that not all data types can be demoted and also fields that are within a repeating context cannot be demoted. For data types that don't allow demotion, the checkbox will automatically be disabled.
    Once you enable certain fields for demotion, they become available in SharePoint's data grid view to be edited. The data grid view can be accessed from SharePoint library using the Actions menu as shown below.
    Also since demotion happens on SharePoint side (when the field is edited), the form's business logic such as Data Validation, Rules, Formulas, Code and Script will not run at that time. So there may be situations when you do not want to turn on demotion for certain fields.
    Hope you find this helpful and look forward to see you turning on demotion.
    Lead Software Development Engineer
  • Microsoft InfoPath 2010

    Compatibility between InfoPath 2003, 2007, and Forms Server

    Ask and ye shall receive. Here's a short summary of how to think about compatibility when designing form templates in InfoPath 2007.
    1. InfoPath 2003 forms will work as-is in 2007
    Your existing forms should work. Period. If you find something that doesn't work, please leave a comment so we can get that bug fixed.
    2. InfoPath 2007 can save as InfoPath 2003 forms
    Most features actually work in 2003, we just made 2007 the default to be forward-looking. If you plan to design all your forms to be compatible with InfoPath 2003, you can change the default in the Options dialog off the Tools menu:
    You can also save individual forms as the file type 2003:
    When you save a file for InfoPath 2003, we automatically check this box in Form Options:
    So that the design checker will show you compatibility issues:
    You can get more info on each issue by clicking it, and then fix it appropriately. Forms with "Messages" will successfully save for 2003, but forms with "Errors" cannot be saved for 2003 until all the errors have been fixed.
    3. InfoPath 2003 forms can also work on the Forms Server
    If you have the InfoPath 2003 client rolled out to your desktops, and also have the Forms Server, then you can create forms that will open in the browser for people without any copy of InfoPath, but open in the client for those with InfoPath 2003 (and 2007, see point 1 above).
    First, follow the steps above to save your form to be compatible with InfoPath 2003. Then check this box in Form Options to make the form browser-compatible:
    Now you can fix any remaining issues shown by the design checker, and publish the form to Forms Server the same as any other browser-enabled form.
    Hope that helps,
  • Microsoft InfoPath 2010

    Getting the XPath without straining your brain

    Yesterday I talked about using System.Xml in the new object model. My code examples included a key part of the InfoPath programming model: looking up fields in the data source using XPath so that you can set and get values.
    Unfortunately, figuring out the absolute XPath to a field can be a pain.
    Fortunately, we've made that easy in InfoPath 2007.
    Here's how
    Right click the field in the Data Source task pane and click Copy XPath
    Now you can paste the XPath into your code and be on your merry way.
    Hope that helps,
  • 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. 
Page 1 of 1 (11 items)