Microsoft InfoPath 2010
The official blog of the Microsoft InfoPath team

March, 2007

  • Microsoft InfoPath 2010

    Associating a Custom Document Information Panel with an Office Document


    When a custom Document Information Panel is associated with an Office document and/or template, the information needed to locate the Panel is contained in a custom XML data part stored with the document.
    I won’t go into the details of the way an Office Open XML document is structured here (needless to say there are many great resources for this on the web), but the format is basically a ZIP file with a collection of XML files that describe the contents of the word processing, spreadsheet, or presentation. Those XML files are linked to each other via logical “relationships” that define the necessary semantics (e.g. that one file contains the content for the header).

    In the terms familiar to the Office Open specification, a custom XML data part is stored at the following location in an Office Open XML document:

    Basically, the data is stored in an XML file which is logically related to the main part for that file type, and whose logical relationship is of type “customXml”.
    Now then, the other half of the definition of a custom Document Information Panel is the content of that custom XML data part. Here’s an example of the data stored in the custom XML data part for a custom Document Information Panel:

    <customPropertyEditors xmlns="">

    This part defines the settings for the Document Information Panel by using the following four elements:

    Element Name Definition
    showOnOpen This element specifies whether the Document Information Panel should automatically be displayed when the document is opened and the first time it is saved.
    defaultPropertyEditor This element specifies which Document Information Panel template should be shown first when the Panel is made visible (either automatically or by the user).

    The contents of this element are one of two choices:
    Standard properties – this setting shows the default Office 2007 property template
    <custom XML namespace> - if the template to be shown should be a custom Document Information Panel stored with the document, its root XML namespace is stored in this element, so Office can locate and display this information automatically when the Document Information Panel is shown

    XMLNamespace The root XML namespace of the custom Document Information Panel. If this template is the one which should be shown automatically, this value is the same as the value of the defaultPropertyEditor element.
    XSNLocation The location of the InfoPath form template to be shown in the Document Information Panel. This location can be of either of the following forms:
    • File path to the InfoPath form template.
    • The URN of the form template if it is a template installed on the target computer.

    With that information defined, Office automatically locates a custom Document Information Panel and displays it as requested. Note that none of these steps involve using Office to set up the Document Information Panel – this process can be automated without Office (for example, to add a Document Information Panel to a template as part of a server-based process).

    Alnur Ali
    Program Manager

  • Microsoft InfoPath 2010

    Submitting to a SharePoint List


    As you know, submitting to a Microsoft Windows SharePoint form library from an InfoPath form is quite simple: just add a “submit” type of data connection to InfoPath and away you go. However, submitting to a SharePoint List is another matter. In this post, we will take a look at the steps necessary to enable this functionality.

    Step 1: Create the list

    1. Create a new custom list named: MyContacts
    2. From the Settings button choose List Settings
    3. Click Create Column
    4. Add the following columns/data types:

    • FirstName, Single line of text
    • LastName, Single line of text
    • Email, Single line of text
    • Phone, Single line of text

    The next step is to create a Collaborative Application Markup Language (CAML) template that contains the same XML nodes as the columns we added to our list – this will be used as a secondary data connection in the InfoPath Form Template.

    Step 2: Create the CAML template

    1. Launch Notepad (or any text editor)
    2. Copy and paste the following code to the Notepad document:

    <?xml version="1.0" encoding="UTF-8"?>
    <Batch OnError="Continue">
        <Method ID="1" Cmd="New">
            <Field Name='Title'></Field>
            <Field Name="FirstName"></Field>
            <Field Name="LastName"></Field>
            <Field Name="Email"></Field>
            <Field Name="Phone"></Field>

    3. Save this as: Add List Item Template.xml


    Step 3: Create the InfoPath Form Template

    1. Create a new, blank, browser-compatible form template
    2. Add a “Receive” type secondary data connection to the Add List Item Template.xml file created in Step #2. (Make sure the options “Include the data as a resource file in the form template” and “Automatically retrieve data when the form is opened” are enabled.)
    3. Add a “Receive” type secondary data connection to the “MyContacts” SharePoint List created in Step #1 and make sure the option “Automatically retrieve data when the form is opened” is enabled.
    NOTE: Be sure to include the “Title” field along with the custom fields we created.

    Each SharePoint list is created with a unique identifier called a GUID. In order to submit items to a SharePoint list, you must know the unique GUID for that list. These next steps will enable you to identify the GUID for your “MyContacts” list.

    Step 4: Identify the list GUID

    1. Open a browser and navigate to the MyContacts list
    2. From the Settings menu choose List Settings
    3. In the browser’s address bar you will see the URL appended with “List=”


    4. Copy everything after the equals sign and paste this into a text editor as we will need this value later on.

    NOTE: We will need the list GUID to be formatted as “{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}”. If your GUID appears as above with the hyphens and braces “escaped” (i.e. %7B for the braces and %2D for the hyphens) then you will need to replace the escaped characters with the braces and hyphens so when we use this GUID later, it will appear as: {1E76517B-2C36-4473-A420-A737D98589BC}

    Step 5: Add controls to the InfoPath Form Template

    1. Open the Data Source Task Pane
    2. From the Data Source dropdown box choose the “MyContacts” connection

    3. Right-click on “MyContacts” and choose Repeating Table – this will add a repeating table bound to that connection to your View
    4. From the Data Source dropdown box choose Main
    5. Add a text box to the “myFields” node named: ListName and set the Default Value property to the GUID value of your list – we will use this node to specify the list when we perform the Submit operation


    To update the SharePoint list we will be using the “UpdateListItems” method of the SharePoint “lists.asmx” web service. This web method requires a couple of parameters (the list name and what gets updated) – now that we have added the “ListName” node which contains the GUID and we have the Add List Item Template XML data connection which describes our data structure we have all the necessary information to add the “UpdateListItems” web method!

    Step 6: Add the “lists.asmx” web service

    1. Add a new “Submit” type of web service data connection to the “lists.asmx” web service – this is typically located at: http://servername/_vti_bin/lists.asmx
    2. Select the “UpdateListItems” operation
    3. Double-click the “listname” parameter and assign the “my:ListName” node as the value

    4. Double-click the “updates” parameter, select the “Add list Item Parameter” data source, select “Batch” and click OK
    5. For the “Include” option select “XML subtree, including selected element”

    6. Complete the Data Connection Wizard

    Now that we have all the connections that are required, we now need to add the “submit” functionality to the form template.

    Step 7: Add Submit functionality

    1. Display the Data Source Task Pane
    2. From the Data Source dropdown box choose the Add List Item Template data connection
    3. Drill down through the data source, right-click on the Field node and choose Repeating Table


    We need to change the text box control in the “Name” column to Read-only – if these values were to be changed it would affect the CAML and the submit would fail.
    • Double-click on the text box in the Name column of the Repeating Table
    • Select the Display tab
    • Enable the Read-only property and click OK
    • Add a new Button control to the View
    • Double-click the button to display the Properties
    • Click the Submit Options button
    • Enable the option “Allow users to submit this form”
    • Enable the option “Perform custom action using Rules” and click the Rules button
    • Click the Add button
    • Click the Add Action button
    • From the Action dropdown box choose “Submit using a data connection”, select the “Web Service Submit” data connection and click OK
    • Click the Add Action button
    • From the Action dropdown box choose “Query using a data connection”, select the “MyContacts” data connection and click OK (this will automatically refresh the list in InfoPath so you can see the newly added record)

    • Click OK until you are back to your form

    NOTE: If you want to automatically clear out the submitted values, add another action to this Rule to “Set a field’s value” and the only option you need to specify is the “Field” option – select the “Field” node from the “Add List Item Template” data connection and then simply leave the Value option blank.

    Step 8: Test!

    1. Click the Preview button to preview the form
    2. Fill in values for each of the fields: Title, First Name, Last Name, E-mail and Phone

    3. Click the Submit button – the contact information should be submitted successfully and the “MyContacts” list automatically updated!

    A special thanks to Matt Faus of InfoPathDev for for initially posting this solution!

    Scott Heim
    Support Engineer

  • Microsoft InfoPath 2010

    InfoPath Data Connections: Part 1



    This article is part of a series of documents explaining the Data concept in Microsoft Office InfoPath. This particular article is an overview of how Data Connections work in InfoPath. The intended audience is those who are new to InfoPath and those who use InfoPath, but have not built up knowledge in the way Data Connections work. For more exhaustive information regarding specific types of data connection, see the Links section at the end of this article.


    Definitions of certain terminology in this paper are as follows:

    • InfoPath client – the software program named "Microsoft Office InfoPath"
    • Designer – The person who is using the InfoPath client to create/design a form template
    • Form template – the XSN file that is created with InfoPath client and used to enter data by the form filler
    • Filler – the person who is putting data into the form
    • Form – a form that is either filled out or in the process of being filled out by the filler. Also known as the InfoPath XML file. 
    • Document Object Model (DOM) – XML structures in the form.  In InfoPath, there is a Main DOM on which the form is based and Secondary DOMs which hold data received from Receive Data Connections.


    The purpose of using an InfoPath form is to collect structured data. This data structure is represented by a schema (XSD) which defines the data fields and the hierarchical structure of the data.

    When using InfoPath client, data is accessible through data connections. These data connections are defined in the form template and used at runtime. During design of the form, the form designer will create the data connection. The designer must choose to either create new settings for a data connection or search for existing connections previously defined by an admin on a SharePoint server. In general, the data connection paradigm in InfoPath 2003 and 2007 is such that data connections are grouped into one of two types – submit connection type or receive (query) connection type. Receive connection types have a one-to-one relationship with secondary DOMs.


    Submit Data Connections

    Consider this scenario. The form filler places data into all of the fields on the form, presses a button labeled “Submit my data” and the data is pushed to some listener where it can be stored or processed.

    As simple as this scenario is, it must be configured by the form designer through the Submit type of data connection. After creating a submit data connection, the designer can apply the data connection to a user action – in this case, the button labeled “Submit my data”. When the filler executes that action, data in the main DOM of the form is transmitted to the target of the data connection as a submission.

    Submit data connections can currently bind to the following destinations:

    • Web Service – Using a data connection bound to the Web Services adapter, data is submitted according to the specifications of the web service.For web services that expose the type System.Dataset, InfoPath will track changes as the user edits the data.  When the data is submitted to the web service, the changes are sent using ADO.NET Diffgrams.
    • SharePoint document library – Data is submitted to a SharePoint document library by using a data connection bound to the SharePoint Document Library adapter.
    • E-mail – Using a data connection bound to the SMTP E-Mail adapter, this enables the submission to an e-mail address. The settings of the data connection can specify whether to submit the entire contents of the form as an attachment or just the current view as the body of the e-mail message.
    • The form hosting environment, such as an ASP.NET page or a hosting application (2007 ONLY) – Using a data connection bound to the “Submit to host” adapter, this raises a submit event to the host. The host is then responsible for handling that event and retrieving the data from the form. See for more info. 
    • Web Server (HTTP) – This is one exception where the submission is not bound to an adapter as a data connection, rather, the settings of the submit options on a control specify an HTTP URL. HTTP Post is used to submit the data in the form to that URL.
    • Database – Lastly, if the form is initially designed from a SQL Server or Access database, a submit action can be created to push the data back into that database. Note: the database option has some caveats in that large binary types cannot be submitted from InfoPath directly; these require a web service in front of the database.


    Receive Data Connections

    One of the major problems in filling out forms is accuracy of data. For instance, if someone was replying to a survey regarding what their favorite programming language is, they could have a text box to type it in. Now imagine that there are 50 respondents to the survey, each trying to explain in a text string what their favorite language is. Consider for a moment that it is C#. They could respond with any of the following and be just a correct or valid: C#, C-Sharp, Csharp, C, C# .NET. Obviously, allowing this type of data entry will create problems when the survey is interpreted.

    This type of scenario is a good reason to use a Receive data connection. What if the form designer was to pre-populate a drop-down control with specific choices which the filler could choose as their favorite programming language? The designer could create a list such as: VB, C++, VB.NET, C# and would thus ensure that the filler would be able to be successful in filling out the form with valid data that is consistent across all of those who respond. The person who aggregates the responses from the form will also be able to ensure that they have interpreted the data correctly and completely.

    To configure this scenario, the form designer now needs to create a Receive connection type. A receive data connection allows a query to be made to get data from an external source and return it to the form. External data is placed into the form as a secondary data source (represented as another DOM). Controls can then be configured to use these fields. Also, the designer can view the additional data sources by viewing the Data Source task pane and using the drop down to switch between data sources. If the dropdown is grey, then there is only one data source in the form.

    Receive data connections can currently connect to the following sources - all of these are supported in InfoPath 2003 and 2007: 

    • XML Document – This includes any URL that would return an XML document (For instance, an RSS feed)
    • Database (Microsoft SQL Server or Microsoft Access only)
    • Web Service
    • SharePoint document library or list



    For further and comprehensive information regarding data connections in InfoPath, see

    For more information specific to data connections to Web Services, see

    For more information on using InfoPath with Access, see

    For more information on using InfoPath to connect to SharePoint data sources, see

    For general topics of interest and further How To information on InfoPath data connection, see

    Patrick Smith
    Program Manager

  • 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

    Do You Love Access? We do too!


    And that's why there's all the new-and-cool documentation about how to make your InfoPath forms work well with Access:

    And a few bonus articles, also from our friends in the documentation team:

    Happy Friday!

  • 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

    SQL Server 2005, Part III: Magic of Structured Search


    You were patient enough to read through my ramblings about why Yukon and InfoPath are a match made in heaven, and how to set up basic interop. But these two articles left you dreaming of more. Well, that was their purpose :-).

    Magic begins: Structure-aware query. Full text search is, ahem, much less powerful.

    Just imagine: you built your resume system. HR folks can search the records by the first and last name of the candidate. Useful, but far from magical. HR comes to you and says: "hey, we want to search by years of experience!"; next day, the way to search by job title, then, they want to see candidates with EA experience...

    Query parameters keep coming every week. You're getting sick of modifying the system; maintenance costs are growing. Programming the system is no longer fun.

    Well, that was yesterday.

    Today, with Yukon, you can build dynamic queries for your customers on the fly: this involves writing an XPath expression or two. In the next few steps, we'll assume that you have the basic setup completed (if not yet, follow this article).


    Start with the goal

    Here's what we're trying to build:

    Works like this: pick the property you want to search (the list is dynamic); select a value that you want to search that property for; then click Run Query. This performs a few calculations, then calls a web service, and shows the result set. Then, the user can drill down on each record using the Details button.

    Why? Where's the magic? HR comes and says "I want another query criteria", and you deliver it by authoring one line of XPath in an InfoPath form. No form template modifications, no web service modifications, no C# to write.

    Here's what the end goal looks like at design time:

    Going through the building blocks:

    1) fieldToSearch dropdown: this is the core of the magic. Here you specify key-value pairs for "what XPath you want searched vs the name of the search". For example, the Job Title search option that you see on the screenshot above maps to a smart-y XPath 


    You can conceptually see that the JobTitle node will be searched for values specified somewhere. Hey, you might ask, where's that printf() syntax coming from?? You'll see an answer soon - we'll be doing a substitution of %1 for a real value coming from the fieldValue node in the web service code, described in detail below.

    The key-value pairs for this dropdown would likely come from a secondary data source - an XML file that you'd keep separately, and author using another InfoPath form. Here are some sample values:

    Display Name of
    the field to query
    Search XPath (value)
    Name //ns:Name[//ns:Name.First = "%1" or //ns:Name.Last = "%1"]
    Job Title //ns:Emp.JobTitle[contains(.,"%1")]
    Job State //ns:Location[ns:Loc.State = "%1"]

    2) fieldValue textbox: this allows the user to specify the value to search for. In the example above, they said that they want to search the "Title" field for the word "Manager".

    3) Run Query button: has a rule on it, with a few actions - using the Logic Inspector:

    Here we're setting the parameters on the secondary data connection that queries a web service; here's a screenshot of its data source:

    Why are we hard-coding the select XPath? Just for this example, it's likely that the basic info would be "show me the first and last names, and if I want to drill down, I will". Everything else is dynamic; if you'd like, you can specify selectXPath dynamically in the separate XML file mentioned in step 1.

    Now the web service method source code - the beauty is that it's completely generic, and you don't have to change anything in the web service

    /* criteriaXPath must contain %1. It will be used to substitute in the criteriaValue
    * selectXPath must point to one, and only one text node (concat's are fine -
    *          just make sure that result can be casted to varchar)
    * None of the parameters should have a single quote in them: this is just a ,
    *          you may want to improve this before going to production (escaping).
    public XmlDataDocument DoXQuery(string criteriaXPath, string criteriaValue, string selectXPath)
        XmlDataDocument result = null;
        string criteria = criteriaXPath.Replace("%1", criteriaValue);

        using (SqlConnection conn = new SqlConnection(connString))
            string command = @"
                WITH XMLNAMESPACES (
                    '' AS ns

                    JobCandidateID AS id,
    + selectXPath + @"',  'nvarchar(128)') AS value
                FROM "
    + tableName + @"
                WHERE Resume.exist('"
    + criteria + "') = 1";
            SqlDataAdapter myCommand = new SqlDataAdapter(command, conn);
            DataSet ds = new DataSet();
            myCommand.Fill(ds, "JobCandidates");
            result = new XmlDataDocument(ds);
        return result;


    And you're done!

    Alex Weinstein
    Program Manager

  • Microsoft InfoPath 2010

    InfoPath 2007 Training Labs


    I’m pleased to announce that InfoPath 2007 training labs are now live on MSDN. Just like with the hands-on labs for InfoPath 2003, we created a set of exercises that walk you through a real-life scenario, introducing a new InfoPath feature in the process. Here are the new labs:

    Lab 1: Publishing an InfoPath 2007 Form Template to a Server Running InfoPath Forms Services
    Lab 2: Deploying and Managing InfoPath 2007 Forms
    Lab 3: Integrating InfoPath 2007 with the Data Connection Library
    Lab 4: Enabling Digital Signatures in InfoPath 2007 Form Templates
    Lab 5: Importing Word Forms into InfoPath 2007
    Lab 6: Using InfoPath 2007 E-mail Forms
    Lab 7: Restricting Permissions to InfoPath 2007 Forms and Form Templates
    Lab 8: Using the InfoPath 2007 Object Model and Visual Studio Tools for Applications
    Lab 9: Designing InfoPath 2007 Forms for Mobile Web Browsers
    Lab 10: Creating and Inserting InfoPath 2007 Template Parts
    Lab 11: Integrating InfoPath 2007 Forms in Web Sites Using Visual Studio
    Lab 12: Using SharePoint Server Workflows with InfoPath 2007

    Many InfoPath 2003 labs are still relevant - so if you need a refresher on fundamentals, here's the list:

    Lab 1: Editing forms and working with form data (Level 100)
    Lab 2: Creating forms and layout (Level 200)
    Lab 3: Form deployment (Level 200)
    Lab 4: Working with controls (Levels 200 and 300)
    Lab 5: Business logic (Levels 200 and 400)
    Lab 6: Active X controls (Level 400)
    Lab 7: User roles (Level 200)
    Lab 8: Working with data sources (Levels 300 and 400)
    Lab 9: Working with ADO.NET DataSets (Level 400)
    Lab 10: Digital signatures (Levels 300 and 400)
    Lab 11: Advanced form merging (Level 400)
    Lab 12: Workflow support (Level 400)
    Lab 13: Working with schemas (Level 300)
    Lab 14: Working with custom task panes (Level 400)
    Lab 15: Business logic using managed code (Level 400)
    Lab 16: External automation (Level 400)

    Alex Weinstein
    Program Manager

  • Microsoft InfoPath 2010

    Get the User Profile through MOSS Web Services


    It is now easier than ever to pre-populate your InfoPath 2007 forms with the user profile information of the current user.


    In Microsoft SharePoint Server 2003, the UserProfileService.GetUserProfileByName(string accountName) web service method required the caller to pass the account name (e.g., domain\alias) associated with the user profile to retrieve.  Though required, this argument was not needed when retrieving the profile of the current user.  After all, the form was running with the network credentials of the current user and those credentials were passed to the web service.

    The typical work-around was to deploy a custom WhoAmI web service as a façade for the UserProfileService.  This façade would provide a method (e.g., WhoAmI() ) that would detect the user's identity and effectively forward a call to the UserProfileService, returning the eventual result to the caller.

    New for Microsoft Office SharePoint Server 2007 and InfoPath 2007:

    In InfoPath 2007, you can get the logon name of the current user by just using a new built-in function; but what if you need to get more data than just the username? Manager name, phone number, office location, and other data are all accessible through the UserProfileService: read on.

    A form that uses the UserProfileService of MOSS to retrieve the User Profile of the current user no longer needs to explicitly pass the account information of the current user to the GetUserProfile method of the UserProfileService.  Simply passing a null value to this method will cause the web service to grab the user identity from the request.  The web service will then use that information as the account name and will subsequently return the User Profile of the current user.

    Use this technique when you want to pre-populate the fields of an InfoPath 2007 form with user information obtained from the MOSS 2007 User Profile Database. 

    The following instructions detail how to build a form to demonstrate this capability.


    • The default MOSS web application is configured to use Windows Authentication.
    • The MOSS server has an SSP with a User Profile Database that has been loaded from Active Directory
    • The end-user has a profile in the User Profile Database of the MOSS server
    • The end-user is logged into the client machine using his/her domain account.


    Step 1: Create the form

    1. Open InfoPath and design a new, blank form
    2. Save the form as UserProfileDemo.xsn

    Step 2: Design the form

    1. From the Layout Task Pane, add a 2 column x 4 row table to the form
    2. Place labels into the column 1 as follows: Name, Account, Email, and Phone
    3. Using the Controls Task Pane, drag four text box controls to your form, placing one in each row of column 2
    4. Using the Data Source Task Pane, rename the four "fieldX" data elements as follows: userName, userAccount, userEmail, and userPhone


    Step 3: Set the security level of the form

    1. From the Main Toolbar, select Tools | Form Options
    2. Select Security and Trust from the list box
    3. Clear the checkbox next to Automatically determine security level
    4. Select Full Trust
    5. Hit OK.

    Step 4: Add code to the form

    1. From the Main Toolbar, select Tools | Programming | Loading Event
    2. Right-click on UserProfileDemo node of the Project Explorer and choose Add Web Reference
    3. Enter the following for the URL: /_vti_bin/UserProfileService.asmx">http://<yourServerName>/_vti_bin/UserProfileService.asmx
    4. Enter the following for Web reference name: ProfileService
    5. Click Add Reference
    6. Replace the FormEvents_Loading event handler with the following code snippet:
    public void FormEvents_Loading(object sender, LoadingEventArgs e) {
        XPathNavigator myRoot = MainDataSource.CreateNavigator();
        ProfileService.UserProfileService profileService = new ProfileService.UserProfileService();
        ProfileService.UseDefaultCredentials = true;
        ProfileService.PropertyData[] userProps = null;
        try {
            // Passing null to this method causes the profile of the current user to be returned.
            userProps = profileService.GetUserProfileByName(null);
        catch { }
        if (userProps == null || userProps.Length == 0) {
        for (int i = 0; i < userProps.Length; i++) {
            XPathNavigator node = null;
            switch (userProps[i].Name.ToLower())  {
                // these property names can be obtained by reviewing the user profile properties in the MOSS SSP.
                case "preferredname":
                    node = myRoot.SelectSingleNode("/my:myFields/my:userName", NamespaceManager);
                case "accountname":
                    node = myRoot.SelectSingleNode("/my:myFields/my:userAccount", NamespaceManager);
                case "workemail":
                    node = myRoot.SelectSingleNode("/my:myFields/my:userEmail", NamespaceManager);
                case "workphone":
                    node = myRoot.SelectSingleNode("/my:myFields/my:userPhone", NamespaceManager);
            ProfileService.ValueData[] values = userProps[i].Values;
            if (values.Length > 0) {
                if (node != null && string.IsNullOrEmpty(node.Value)) {


    Step  5: Build and Preview

    1. Build the project and close VSTA.
    2. From the Main Toolbar, select File | Preview| Form
    3. When the form loads, the text boxes will be populated with your User Profile Information

    This example opens the door to simplifying the form submission process for your users by reducing the time they take to complete forms, as well as ensuring the accuracy of the data that they enter.

    Ronald Tielke
    Microsoft Consulting Services
    Desert Mountain District

  • Microsoft InfoPath 2010

    Enabling InfoPath IntelliSense Documentation in VSTA and Visual Studio


    The Microsoft Office InfoPath 2007 setup program installs two .xml files that are designed to display programming information from the Class Library reference inline in the Code Editor and the Object Browser when working with members of the Microsoft.Office.InfoPath and Microsoft.Office.Interop.InfoPath.SemiTrust namespaces.

    Displaying Programming Information in the Code Editor


    Displaying Programming Information in the Object Browser

    For this programming information to be visible in the Visual Studio Tools for Applications (VSTA) and Visual Studio development environments, you must copy the two .xml files from the InfoPath setup directory into the locations in the Global Assembly Cache (GAC) where each of the InfoPath assemblies are installed. To do that, you use the Command Prompt to copy the files as described in the following steps.

    To copy the IntelliSense documentation files for the Microsoft.Office.InfoPath and Microsoft.Office.Interop.InfoPath.SemiTrust assemblies into the GAC:

    1. Open the Command Prompt.
    2. Execute each of the following commands, pressing Enter after each command:

    cd \Program Files\Microsoft Office\Office12

    copy Microsoft.Office.InfoPath.xml %windir%\Assembly\GAC_MSIL\Microsoft.Office.InfoPath\

    copy Microsoft.Office.Interop.InfoPath.SemiTrust.xml %windir%\Assembly\GAC\Microsoft.Office.Interop.InfoPath.SemiTrust\

    Note   If you are running Windows Vista and using User Account Control, you must right-click the shortcut used to open the Command Prompt, and then click Run as administrator to successfully copy the .xml files into the GAC.

    Mark Roberts
    Programming Writer

  • Microsoft InfoPath 2010

    MSDN Community Content


    All Office InfoPath 2007 developer documentation that is published online in the MSDN Library now supports the MSDN Community Content features that enable users to comment on, edit, and add content to online documentation.

    We would like to encourage you use these features to add code examples and brief pieces of information that will be useful to other users of the documentation (worldwide!). To do so, click the Add new Community Content link, which is located under the Community Content heading at the bottom of each page, and then log in using your Windows Live ID:

    For more information about using MSDN Community Content features, see the MSDN Community Content FAQ.

    The different reference components of the InfoPath 2007 Developer Documentation are located in the following areas of the MSDN web site:


    Development Area/Object Model


    New InfoPath 2007 Managed Code Object Model

    Covers the classes and members of the Microsoft.Office.InfoPath namespace that are new in InfoPath 2007 for creating managed-code business logic in browser-compatible form templates that are deployed to Office Forms Server 2007 or Microsoft Office SharePoint Server 2007 with InfoPath Forms Services.

    InfoPath 2003-Compatible Managed Code Object Model

    Covers the classes and members of the Microsoft.Office.Interop.InfoPath.SemiTrust namespace for maintaining/extending managed code form template projects created with the InfoPath Toolkit or creating new managed code form templates that are compatible with InfoPath 2003.

    InfoPath Managed Code External Automation Object Model

    Covers the classes and members of the Microsoft.Office.Interop.InfoPath namespace for writing managed code to automate InfoPath from an external application.

    COM and Scripting Object Model

    Covers COM object model for InfoPath form template business logic written using JScript and VBScript, as well as external automation from Application and XDocuments objects using COM, plus the COM interfaces for creating form converters.

    Microsoft Office Forms Server 2007 Automation Object Model

    Microsoft Office Forms Server 2007 Automation Object Model

    Covers the classes and members of the Microsoft.Office.InfoPath.Server.Administration namespace for writing managed code to automate server tasks, such as verifying and uploading form templates from code running on Office Forms Server 2007 or Microsoft Office SharePoint Server 2007 with InfoPath Forms Services.

    XmlFormView Control Object Model

    Covers the classes and members of the Microsoft.Office.InfoPath.Server.Controls namespace that are used to work with the functionality of the XmlFormView control, which is used to host InfoPath form templates in custom Web pages on Office Forms Server 2007 or Microsoft Office SharePoint Server 2007 with InfoPath Forms Services.

    InfoPath 2007 XSF Schema Reference

    Covers the XML Schema definition for the InfoPath form definition file (.xsf). This schema defines the types, elements, and attributes used in the manifest.xsf file of an InfoPath form template file (.xsn).


    Note: In addition to the reference content listed above, all of the conceptual and procedural topics in InfoPath 2007 Developer documentation in the MSDN Library also supports the MSDN Community Content features.


    Mark Roberts
    (on behalf of the InfoPath Developer Documentation team)

Page 1 of 1 (11 items)