Microsoft InfoPath 2010
The official blog of the Microsoft InfoPath team

  • Microsoft InfoPath 2010

    New InfoPath content on the web

    • 7 Comments

    I wanted to take a moment to recognize the great work of the Microsoft writers and editors who have been cranking out InfoPath content over the last few months.  While we in the product team have clicked over into Office 14 mode, they have continued to serve customers by creating Office 2007 content – everything from video demos to highly technical developer content.  Here’s some of the content that has been released since RTM.  Thanks to Anneliese Wirth, Arsenio Locsin,  Amy Miller, Anthony Labriola,  Kelley Vice, Tonda Kiffin, David Longmuir, Roger Haight,  and Mark Roberts for getting this information into the documentosphere!

     

     

    November 2006:

    -          Demo: Convert a Word document into an InfoPath 2007 form template

    -          Demo: Use InfoPath e-mail forms to view data in Outlook 2007

    -          Demo: View the business logic in an InfoPath 2007 form template

     

    April 2007:

    -          Article: How to: Share InfoPath 2007 Template Parts and ActiveX Controls

    -          Article: Hosting the InfoPath 2007 Form Editing Environment in a Custom Web Form

     

    May 2007:

    Article: How to: Evaluate and approve a form template

    Article: Guidelines for Creating InfoPath 2007 Converters

     

    June/July 2007:

    -          Article: Working with XML Data Using the XPathNavigator Class in InfoPath 2007 Form Templates

    -          Article: Guidelines for using colors, fonts, and images in a form template

    -          Article: Converting InfoPath 2003 Managed Code to the New InfoPath 2007 Object Model

     

    In addition some content that has been missing from MSDN has been re-published:

     

    -          InfoPath 2003 SDK:   http://msdn2.microsoft.com/en-us/library/bb190871(office.11).aspx

    -          InfoPath 2003 technical articles: http://msdn2.microsoft.com/en-us/library/bb191012(office.11).aspx

     

    We also have some excellent articles written by David Gerhardt of 3Sharp

    -           Developing InfoPath 2007 Managed-Code Solutions.

    -          Pulling CRM Data into InfoPath 2007 Browser Forms 

     

    And finally, InfoPath MVP Ben Walters just posted a code sample which shows how to limit the contact selector control to  single selection:  http://msmvps.com/blogs/benwalters/archive/2007/07/13/contact-selector-the-good-and-the-bad.aspx

     

    Enjoy!

  • Microsoft InfoPath 2010

    How to Integrate the .NET Framework SDK Documentation with VSTA

    • 7 Comments

    The .NET Framework 2.0 SDK documentation includes the Visual Basic and Visual C# language references, as well as the documentation for the .NET Framework classes. You can download and integrate this documentation into the Help viewer for the Visual Studio 2005 Tools for Applications (VSTA) integrated development environment (IDE) that ships with InfoPath 2007. After doing so, the NET Framework 2.0 SDK documentation will be available along with the "InfoPath Developer Reference for Managed Code Form Templates" documentation in VSTA IDE Help viewer for use offline.

     
     
     
     
    .NET Framework SDK Help in the VSTA Help Viewer
     
    Important   If you are running under Windows Vista with user account control, you must start InfoPath 2007 as an administrator before performing the following procedure. To do that, navigate to C:\Program Files\Microsoft Office\Office12, right-click INFOPATH.EXE, and then click Run as Administrator. If you are not running InfoPath as an administrator, you will be unable to complete the following procedure.
     

    To integrate the .NET Framework 2.0 SDK documentation with the VSTA IDE Help

    1. Start InfoPath 2007, and open or create a form template in design mode.
    2. On the Tools menu, click Programming, and then click Microsoft Visual Studio Tools for Applications.
    3. In VSTA, click Index on the Help menu.
    4. Search for Collection Manager, Help, to open the Visual Studio 2005 Tools for Applications Combined Help Collection Manager topic.
    5. Select the check box for the Microsoft .NET Framework 2.0 SDK Documentation in the list of available help collections at the bottom of the topic below Collections available for the default combined Help collection.
      If the .NET Framework 2.0 SDK documentation does not appear in the list of available Help collections, you must install the .NET Framework 2.0 SDK. To install the .NET Framework 2.0 SDK, see http://go.microsoft.com/fwlink?LinkId=9832&clcid.
    6. Click the Update Help Collection button.
     
    You will be asked to close all instances of the VSTA IDE and the Help viewer, Microsoft Document Explorer. When you restart VSTA, the.NET Framework 2.0 SDK documentation will be available in the Help viewer.
     
    - Mark Roberts, Programmer-writer
  • Microsoft InfoPath 2010

    Help Us Improve InfoPath: Send Us Your Forms!

    • 11 Comments

    The Microsoft Office InfoPath Team is interested in seeing how you are using InfoPath.  We would like you to send us your InfoPath forms so we can review them and collect data on how you are using the forms.  We will be using these forms to implement improvements in future versions of Microsoft Office InfoPath. We are interested in looking at a variety of forms ranging from simple to complex (in terms of length, rules, data connections, code, etc.).

    Please send us your forms at ipforms@microsoft.com and include a brief description of how the form is used, what is working well for you and any suggestions for improvement. Also let us know if we can contact you with any follow up questions.

    We cannot guarantee that every form will be reviewed or that the confidentiality of the forms or information contained therein will be maintained.  We ask that you not submit forms containing confidential information.
     
    Thank you for your submissions.  We look forward to hearing from you.
    Microsoft Office InfoPath Team

  • Microsoft InfoPath 2010

    Displaying Contextual Help in a Custom Task Pane

    • 8 Comments

    With all the wonderful features in the new Office apps, it's easy to get lost!  InfoPath is no exception, and when you make clever use of the new features, you'll want to make sure that users understand how your form is supposed to work.  Wouldn't it be great if you could display contextual help information as the user navigates to fields in your form.  With the "Context Changed" event, you can execute custom code when the user filling the form causes the context node to change.  This will fire when the user focuses a control bound to a different DOM node than the current context node.

     

    Files you'll need

    The solution we provide here uses some resource files.  Download the attached files to accomplish the scenario.

    1. "CustomTaskPaneHelp.htm" - The HTML file that will be displayed in the custom task pane.  We will manipulate this document at runtime from custom form code to display the contextually appropriate help information.  Just update the styles in this file to change the appearance of the contextual help in the custom taskpane.

    2. "Help Strings.xml" - This file is a basic xml file that contains mappings from local node names to the title and help contents for the node.  This file will be consulted to retrieve the help information to be displayed in the custom task pane.

    3. "CustomTaskPane.cs" - This helper class wraps the HtmlTaskPane object to access elements in the custom task pane.  This will be added to your VSTA project.

    4. "FormCode.cs" - This contains the code to integrate the custom taskpane into the form template.

    Note that this method works in InfoPath 2003 and 2007, but this tutorial will walk you through the steps in for InfoPath 2007 - the UI is slightly different in 2003, but you can still make it work. Since task panes are a rich-client only feature, this method is not supported in browser-enabled form templates.

     

    Construct your help resource file

    Assuming you've designed your form template already, you'll have a nicely populated data source, replete with variously named nodes.  Now add contextual help data for nodes in the main and secondary data sources:

    1. Open the "Help Strings.xml" file in notepad (or another text editor.)

    2. Add a "Help" element for the data source node:

    • Set the "nodeName" attribute's value to "<node prefix>:<Name in Data Source Pane>"
    • Set the "Title" element's value to the heading that you want to display for this node's contextual help.
    • Set the "Contents" element's value to the body of this node's contextual help.

    3. Repeat step 2 for all nodes for which you want to display contextual help so that you have something like this:

    <?xml version="1.0" encoding="utf-8" ?>
    <HelpStrings>
       <HelpString>
          <Help nodeName="my:TextField">
             <Title>Text Field</Title>
             <Contents>Help for my text field.</Contents>
          </Help>
          <Help nodeName="my:RichTextField">
             <Title>Rich Text Field</Title>
             <Contents>Help for my rich text field.</Contents>
          </Help>
       </HelpString>
    </HelpStrings>

     

    4. Save the file to a shared location

    NOTE:  If you want to be able to update this help data without having to re-deploy the form template, the shared location should be accessible to all users that will fill out the form.  If, on the other hand, you do not care about that, then you can just save the file locally and add it as a resource file to the form template.  See below…

     

    Add the data source that will provide your contextual help data

    Now that you're help strings are all set, we need to add a reference to the help strings so that the form template can access them.  We'll do this by adding a data connection to query the xml file from a shared location or resource file.

    1. Tools >> Data Connections >> Add

    2. Select Receive Data, then XML Document

    3. Specify the location of the help strings document (Help Strings.xml)

    • If, as noted above, you want to include the help strings as a resource file in the form template, just click "Next >". Including the file as a resource file guarantees that it will always be accessible to the form template, but the form template will have to be updated if you need to change the help strings.
    • If, on the other hand, you would like to access the help strings file from a shared network location or web server, then select "Access the data from the specified location" and then click "Next >". Accessing the file from a shared location may fail if the shared location is unavailable, and there may be some delay due to network traffic.

    4. Check the "Automatically retrieve data when form is opened" check box and click "Finish" / "Close".

     

    Enable the custom task pane in your form template

    Custom task panes are not enabled by default.  We'll specify that the custom task pane should be displayed, and its content should be rendered from the "CustomTaskPaneHelp.htm" file.

    1. Tools >> Form Options >> Programming

    2. Check the "Enable custom task pane" check box. Type a name for the custom task pane in the "Task pane name" field.

    3. Add the "CustomTaskPaneHelp.htm" file as a resource file.

    • Click Resource Files >> Add…
    • Browse to the "CustomTaskPaneHelp.htm" file and click Open / OK.

    4. Select "CustomTaskPaneHelp.htm" from the "Task pane location" drop-down list.

     

    Add the code to manage the context change and display the contextual help information

    1. Tools >> Programming >> Context Changed Event; this will create the VSTA project and insert the "Context Changed" event handler.

    2. Add the "CustomTaskPane.cs" file to your project

    • Right-click the top-level project node.
    • Click "Add" >> "Existing Item…"
    • Browse to the "CustomTaskPane.cs" file and click "Add".
    • IMPORTANT: Edit the Namespace of the "CustomTaskPane.cs" file to be the same as that of your form code file.

    3. Integrate the code in the attached "FormCode.cs" file into your VSTA project.  Make sure you copy the contents of the "FormEvents_ContextChanged" method, as well as the private properties and variables.

    4. Build and save your form template.

     

     

    Make the form template full trust

    1. Tools >> Form Options >> Security and Trust
    2. Uncheck the "Automatically determine security level" checkbox. Select the "Full Trust" radio button.
    3. Click "OK"
    4. Save and publish the form template. You will need to publish the form template as an installable form template (.msi) or digitally sign the template; detailed instructions are here.

    Now, when users fill out your form, contextual help will be displayed for each node as the user clicks on a control bound to it.  As long as you've included help information in the help strings file, you'll see the help information in your custom task pane!

    Forrest Dillaway
    Software Design Engineer in Test

  • Microsoft InfoPath 2010

    Associating a Custom Document Information Panel with an Office Document

    • 2 Comments

    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="http://schemas.microsoft.com/office/2006">
          <showOnOpen>
                true
          </showOnOpen>
          <defaultPropertyEditorNamespace>
                http://schemas.microsoft.com/office/infopath/2003/myXSD/2005-10-21T21:12:27
          </defaultPropertyEditorNamespace>
          <customPropertyEditor>
                <XMLNamespace>
                        http://schemas.microsoft.com/office/infopath/2003/myXSD
                </XMLNamespace>
                <XSNLocation>
                        \\contoso-server\forms\assetForm.xsn
                </XSNLocation>
          </customPropertyEditor>
    </customPropertyEditors>

    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

    • 530 Comments

    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>
        </Method>
    </Batch>

    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

    • 17 Comments

    Summary

    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.

    Terminology

    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.

    Background

    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 http://msdn2.microsoft.com/en-us/library/ms778201.aspx 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

     

    Links

    For further and comprehensive information regarding data connections in InfoPath, see http://office.microsoft.com/en-us/infopath/HP012304861033.aspx?pid=CH100598301033

    For more information specific to data connections to Web Services, see http://office.microsoft.com/en-us/infopath/HP100913971033.aspx?pid=CH100598301033

    For more information on using InfoPath with Access, see http://office.microsoft.com/en-us/infopath/HP100950831033.aspx?pid=CH100598301033

    For more information on using InfoPath to connect to SharePoint data sources, see http://office.microsoft.com/en-us/infopath/HP100931601033.aspx?pid=CH100598301033

    For general topics of interest and further How To information on InfoPath data connection, see http://office.microsoft.com/en-us/infopath/CH100598301033.aspx

    Patrick Smith
    Program Manager

  • Microsoft InfoPath 2010

    Transforming InfoPath Rich Text to Word

    • 3 Comments

    This article applies to InfoPath 2003 and Word 2003.

    Summary

    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:


    <w:p><w:r><w:t>
         <xsl:value-of select=”my:EmployeeName”/>
    </w:t></w:r></w:p>

    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.

    Details

    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="http://www.w3.org/1999/xhtml">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=”http://www.w3.org/1999/XSL/Transform”
    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">
      <xsl:text>progid="Word.Document"</xsl:text>
      </xsl:processing-instruction>
    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”/>
    </xsl:template>

    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!

    • 3 Comments

    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!
    Alex

  • Microsoft InfoPath 2010

    Template Parts 101

    • 6 Comments

    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

    • 1 Comments

    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 

    //ns:Emp.JobTitle[contains(.,"%1")]

    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

    [WebMethod]
    /* 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 (
                    'http://tempuri.org/Resume' AS ns
                )

                SELECT
                    JobCandidateID AS id,
                    Resume.value('"
    + 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

    • 3 Comments

    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

    • 37 Comments

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

    Background:

    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.

    Assumptions:

    • 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) {
    
            return;
    
        }
    
        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);
    
                    break;
    
                case "accountname":
    
                    node = myRoot.SelectSingleNode("/my:myFields/my:userAccount", NamespaceManager);
    
                    break;
    
                case "workemail":
    
                    node = myRoot.SelectSingleNode("/my:myFields/my:userEmail", NamespaceManager);
    
                    break;
    
                case "workphone":
    
                    node = myRoot.SelectSingleNode("/my:myFields/my:userPhone", NamespaceManager);
    
                    break;
    
                default:
    
                    continue;
    
            }
    
            ProfileService.ValueData[] values = userProps[i].Values;
    
            if (values.Length > 0) {
    
                if (node != null && string.IsNullOrEmpty(node.Value)) {
    
                    node.SetValue(values[0].Value.ToString());
    
                }
    
            }
    
        }
    
    }
    

     

    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

    • 2 Comments

    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\12.0.0.0__71e9bce111e9429c

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

    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

    • 1 Comments

    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

    Description

    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.

    Thanks!

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

  • Microsoft InfoPath 2010

    Using the Contact Selector Control

    • 398 Comments

    (This post applies to InfoPath 2007. If you're using InfoPath 2010, then you should check out this post instead.)

    We have seen a number of requests on how to allow a user to enter (or select) a person’s name or logon alias and then validate that user against their Active Directory without using code. This has been especially true in workflow scenarios where User A needs to enter in the name of User B – the next person in the workflow process.

    Well, InfoPath 2007 ships with a control called Contact Selector Control that will resolve these issues! You may have seen our older article on the subject; this one aims to dive in deeper.

    The Contact Selector control is an ActiveX control but it is a special cased control, in that it can also be used in InfoPath browser forms. To use this control there are specific steps that need to be taken – let’s take a look at those now.



    Step 1: Add the Contact Selector control to your Controls Task Pane

    1) From the Controls Task Pane click the Add or Remove Custom Controls link

    2) Click the Add button

    3) On the first screen of the Add Custom Control Wizard select ActiveX control and click Next

    4) From the list of controls, choose Contact Selector and click Next

    5) Select “Don’t include a .cab file” and click Next

    6) For Binding Property select Value and click Next

    7) From the Field or group type box choose Field or group (any data type) and click Finish

    8) Click Close and then click OK

     

    Step 2: Create the data structure for the Contact Selector Control

    The Contact Selector control needs to have a specific data structure to work properly – this is documented on the “Items” tab of the Properties screen for the control; however, we’ll include that information here as well.

    **IMPORTANT!** Spelling and capitalization must be exactly the same, starting with the “Person” group!

    1) Add a non-Repeating Group named: gpContactSelector

    2) Add a Repeating Group named: Person

    3) Add the following 3 text fields to the Person group: DisplayName, AccountId and AccountType



    Step 3: Add and bind the Contact Selector control to the View

    1) Drag the gpContactSelector Group to the View and select “Contact Selector” from the list of controls

    2) You’re almost done…! :-)



    Step 4: Add a secondary data source XML file which specifies the SharePoint server

    The Contact Selector control needs to know the “context” of where the user validation should occur. These steps are not necessary if you are only displaying the form in a browser from SharePoint – in this case, it uses the context of the site from where it was provisioned; however, if you are in a mixed client/browser scenario you will need to include this XML file so forms opened in the client can use this functionality.

    1) Launch Notepad

    2) Copy and paste this one-line XML:

    <Context siteUrl="http://<servername>"/>

    **NOTE: Replace <servername> with the name of your server

    3) Save this as: Context.xml (again – naming and capitalization are important)

    4) Add Context.xml as a “Receive” type Secondary Data Connection to your form template and make sure the option “Include the data as a resource file” is enabled



    Step 5: Test!

    You should now be able to Preview the form, enter a name or logon alias, click the “Check Names” button and resolve the name! Alternatively you could click the “To” button to perform a Search if you do not know the complete name of the user.

    One other important point: if this control is something you will use numerous times, this process works great to create a “Contact Selector Template Part” – then you only have to complete these steps one time!

    Scott Heim
    Support Engineer

  • Microsoft InfoPath 2010

    Passing Data into a Form: Input Parameters

    • 29 Comments

    This blog article discusses a new feature of Microsoft InfoPath 2007 that makes it possible to pass data into an InfoPath form at load time. A typical example would be retrieving records from a database for a particular user. At load time a ‘userID’ can be passed into the form. This userID can then be used to query the database and load the form with the user's data.

    Parameters can be passed into InfoPath form templates (XSNs) or InfoPath Forms (XMLs). The syntax for specifying input parameters is the same for both. This article focuses primarily on InfoPath client scenarios, but should apply for the most part to server scenarios as well.

    How to Pass Parameters into an InfoPath Form:

    There are two ways of launching an InfoPath form with parameters

    1) URL

    The syntax for passing parameters via the URL is the standard syntax for query parameters. For example:

    http://www.foo.com/bar.xsn?baz=1&biz=2

    Here two input parameters have been passed into the form namely 'baz' and 'biz'. Their respective values are 1 and 2. The 'Accessing Input Parameters in Form Code' section talks about how these values are stored and accessed in InfoPath code.

    The URL syntax can be used in a number of places like

    • Launching an InfoPath form in a browser by typing the URL into the address bar
    • Pasting the URL to a form or a form template into an email
    • Using the URL inside methods like NewFromFormTemplate, New, Open (XmlForms collection)
    2) Command Line

    The syntax for passing parameters via the command line is as follows:

    infopath.exe “C:\foo\bar.xml” /InputParameters "baz=1&biz=2"

    The switch /InputParameters is used to specify that parameters are being passed into the form, followed by the name/value pairs of input parameters.

    Accessing Input Parameters in Form Code

    Parameters passed into an InfoPath form template or form, are available during the Loading event as a read-only collection of name/value pairs. In order to access these parameters you will need to write code that reads from this collection. The InputParameters collection is exposed in all three InfoPath programming models – it is thus available in JScript, InfoPath 2003 SP1 managed code or InfoPath 2007 managed code. This example uses C# and the InfoPath 2007 managed object model. Syntax for the legacy models follows. The steps below outline how to add code that access the Input Parameters passed into a form.

    1. In the InfoPath designer, click on Tools menu -> Programming menu item.
    2. In the fly-out menu select the Loading event (will be On Load in older InfoPath versions).
    3. This will launch the appropriate IDE (MSE or VSTA or the Visual Studio Toolkit) with the code spit for the loading event inserted.
    4. Add the following code to access the input parameters ‘baz and ‘biz used in the examples above (example is in C# using InfoPath 2007 Managed Object Model)

    public void FormEvents_Loading(object sender, LoadingEventArgs e)

    {

       // Assign the value of the parameter 'baz' to the string 'bazValue'. bazValue = 1

       string bazValue = e.InputParameters["baz"];

     

       // Assign the value of the parameter 'biz' to the string 'bizValue'. bi000zValue = 1

       string bizValue = e.InputParameters["biz"];

     

       // Code that uses the parameters passed in to do whatever needs to be done

       // Example would be to create a custom query using these values and populate a table based

       // on the data returned
    }

    Input Parameter Syntax for Legacy Object models

    The following two code samples contain code for the InfoPath 2003 SP1 Managed Object Model (C#) and Jscript (InfoPath 2003 Object Model)

    1) C# InfoPath 2003 SP1

    In the InfoPath 2003 SP1 Object Model the InputParameters collection is exposed off the XDocument object not off the eventArgs object. Also since this is a new feature the XDocument object needs to be cast to the newer _XDocument3 interface to get access to the InputParameters collection. Hence the first line of code in the sample below.

     [InfoPathEventHandler(EventType = InfoPathEventType.OnLoad)]

     public void FormEvents_OnLoad(DocReturnEvent e)

     {
        
    // Cast XDocument to _XDocument3 to get access to the InputParameters collection
        
    _XDocument3 infopath2007XDocument = (_XDocument3)e.XDocument;

         string bazValue = infopath2007XDocument.InputParameters["baz"].Value;

         string bizValue = infopath2007XDocument.InputParameters["biz"].Value;

     }

    2) JScript

    function XDocument::OnLoad(eventObj)
    {
          var bazValue = eventObj.XDocument.InputParameters["baz"].Value;
          eventObj.XDocument.UI.Alert(bazValue);
    }

    Help

    Comprehensive documentation and additional code samples for this feature can be found under MSE Help or VSTA Help.

    Aditi Desai
    Software Design Engineer in Test

  • Microsoft InfoPath 2010

    New Resources on Office Online

    • 1 Comments

    Our colleagues at Office Online released several interesting InfoPath topics:

    1. Form Data Aggregation and Merging:
      - Design a form for merging 
      - Merge actions for fields and groups
      - Merge InfoPath e-mail form data in Outlook

    2. Document Information Panel:
      - Introduction to designing a Document Information Panel by using InfoPath
      - Design a Document Information Panel by using InfoPath

    3. Workflow:
      - Introduction to using workflows with InfoPath forms
      - Design a form to respond to a workflow status

    Alex

  • Microsoft InfoPath 2010

    Calculating Elapsed Time…without code!

    • 59 Comments

    UPDATE: Due to the number of requests for adding more columns to this sample, I have re-designed the sample. If I have time in the future I will update the steps to create this new design; however, for now you can download the updated design here to see the changes. The expressions are very similar to the original design but I now use a repeating table for entering "break" times so you can have as many as you need! 

    How many times have you needed to calculate the difference between time entries…only to find out the only way to accomplish this was to write custom code? Well no more! If your time entries will not cross days, then you can use a number of functions and expressions to parse the entered times and calculate the difference. In the sample below we will show you the types of expressions that are needed for these calculations to work – I would encourage you to first create this sample as documented as the expressions are not for the “faint of heart!” :-)

    Note: if you choose to copy/paste the expressions for this sample, you will use the Default Value box for each field and after clicking the “fx” button, be sure to also enable the “Exit XPath” option before you paste these expressions.

    If you'd like to take a look at the completed version of this sample, here is the .xsn file - make sure to save it locally before opening it.

    Create the data structure

    1) Add a Repeating Table to your View with 4 columns

    2) Rename the fields and specify the data types as follows, from left to right:

    Name Data Type
    myDate Date (date), Format: *3/14/2001
    StartTime Time (time), Format: *9:46 AM
    EndTime Time (time), Format: *9:46 AM
    ActualTime Text (string)

    3) Change the first field in the table to a Date Picker control

     
    4)  Add 2 additional fields to the Repeating Group node (these will not be shown on the view – they are used to aid in the calculations)

    Name Data Type
    ElapsedTime Text (string)
    TotalMinutes Decimal (double)


    5) Add one final field to calculate the sum of all the entries – this should be added to the myFields node…not the Repeating node

    Name Data Type
    TotalTime Text (string)

    Your final data structure should look like this:

    And your form could look like this:

     

    Adding the expressions…let the fun begin!

    The first step is to convert the StartTime and EndTime values to minutes – this makes the calculation a bit easier. In addition, we don’t want to execute this calculation if either the StartTime or EndTime is blank. So to perform this “conditional statement”, we’ll use the logic explained in this blog entry.

    Step 1: Parse the Hours and Minutes

    1) We first need to parse the “hours” and convert this to minutes by multiplying that value by 60. To do this we will use the “substring-before” function to look for the colon (“:”) in the time field and extract the value before the colon:

    substring-before(../my:EndTime, ":") * 60)
    substring-before(../my:StartTime, ":") * 60

    2) To each of these values, we need to add the minutes that were entered after the colon. Now when time values are stored in the underlying XML, they are stored in this manner: hh:mm:ss. So to pull just the minutes entered, we will use a combination of the “substring-before” and “substring-after” functions since we need the value entered “after” the first colon and “before” the last colon:

    substring-before(substring-after(../my:EndTime, ":"), ":")
    substring-before(substring-after(../my:StartTime, ":"), ":")

    3) Now, at this point we could place each of these expressions together to get the total hours and minutes for each time entry:

    ((substring-before(../my:EndTime, ":") * 60) + substring-before(substring-after(../my:EndTime, ":"), ":"))
    ((substring-before(../my:StartTime, ":") * 60) + substring-before(substring-after(../my:StartTime, ":"), ":"))

    4) Keep in mind, we don’t want this expression to execute if either the StartTime or EndTime fields are empty and we also need to subtract the StartTime total minutes from the EndTime total minutes. So to do this we will use the “substring” function in conjunction with a “condition.” The substring function has the following signature:

    substring([String Value], [Starting Position], [Condition/Length])

    To incorporate our expressions into the substring function, it would look like this:

    Substring([EndTime – StartTime], 1, EndTime != “” and StartTime != “”)

    EndTime expression:

    ((substring-before(../my:EndTime, ":") * 60) + substring-before(substring-after(../my:EndTime, ":"), ":"))

    StartTime expression:

    ((substring-before(../my:StartTime, ":") * 60) + substring-before(substring-after(../my:StartTime, ":"), ":"))

    Starting position: 1

    Condition expression (that if true, evaluates to the length of what we want to return so we use the “string-length” function to get the length of our initial expression):

    (../my:StartTime != "" and ../my:EndTime != "") * string-length(((substring-before(../my:EndTime, ":") * 60) + substring-before(substring-after(../my:EndTime, ":"), ":")) - ((substring-before(../my:StartTime, ":") * 60) + substring-before(substring-after(../my:StartTime, ":"), ":")))

    So our final expression for the TotalMinutes field would look like this:

    substring(((substring-before(../my:EndTime, ":") * 60) + substring-before(substring-after(../my:EndTime, ":"), ":")) - ((substring-before(../my:StartTime, ":") * 60) + substring-before(substring-after(../my:StartTime, ":"), ":")), 1, (../my:StartTime != "" and ../my:EndTime != "") * string-length(((substring-before(../my:EndTime, ":") * 60) + substring-before(substring-after(../my:EndTime, ":"), ":")) - ((substring-before(../my:StartTime, ":") * 60) + substring-before(substring-after(../my:StartTime, ":"), ":"))))

     

     

    Step 2: Convert resulting Total Minutes to hours and minutes

    This expression will use the same basic logic we used above: first divide the resulting total minutes field by 60 to see how many hours have elapsed. If the result of that division contains a decimal point (i.e. 90 minutes / 60 = 1.5) then parse the value before the decimal point (for the hours) and then use the “mod” function to return the balance of the minutes.

    1) We need to divide the TotalMinutes field by 60 to get how many hours have elapsed; however, we also need to check if the resulting value contains the decimal point. So the first expression will use the “substring” function so we can incorporate the conditional test. For the conditional test, we will use the “contains” function to see if the result contains the decimal point:

    contains(../my:TotalMinutes div 60, ".")

    So our initial expression would be as follows: this incorporates the “concat” function so if the resulting value contains a decimal point, we will parse that value, concatenate a colon and the concatenate the result of TotalMinutes mod 60:

    substring(concat(substring-before(../my:TotalMinutes div 60, "."), ":", ../my:TotalMinutes mod 60), 1, contains(../my:TotalMinutes div 60, ".") * string-length(concat(substring-before(../my:TotalMinutes div 60, "."), ":", ../my:TotalMinutes mod 60)))

    2) If the resulting expression does not contain a decimal point, then we will simply concatenate a colon with the results of TotalMinutes mod 60:

    substring(concat(../my:TotalMinutes div 60, ":", ../my:TotalMinutes mod 60), 1, not(contains(../my:TotalMinutes div 60, ".")) * string-length(concat(../my:TotalMinutes div 60, ":", ../my:TotalMinutes mod 60)))

    3) So our final expression for the ElapsedTime field would be as follows:

    concat(substring(concat(substring-before(../my:TotalMinutes div 60, "."), ":", ../my:TotalMinutes mod 60), 1, contains(../my:TotalMinutes div 60, ".") * string-length(concat(substring-before(../my:TotalMinutes div 60, "."), ":", ../my:TotalMinutes mod 60))), substring(concat(../my:TotalMinutes div 60, ":", ../my:TotalMinutes mod 60), 1, not(contains(../my:TotalMinutes div 60, ".")) * string-length(concat(../my:TotalMinutes div 60, ":", ../my:TotalMinutes mod 60))))

     

     

    Step 3: Final Formatting - the ActualTime field

    The way the expression is written for the ElapsedTime field, if the resulting minutes is less than 10, only a single value will be returned (i.e. 0:9). Because of this, we want to test for this condition and if the minutes are less than 10, then concatenate a zero (“0”) before that value so the time appears correct. Now this expression could possibly have been incorporated into the ElapsedTime expression but for ease and clarity, I separated these two steps into different fields.

    This expression uses the “string-length” function to determine the length of the string after the colon. If the length is 2 (minutes are greater than 9) then simply concatenate the hours, a colon and the minutes. However, if the length is 1 (minutes are less than 10) then concatenate the hours, a colon with a zero (“:0”) and the minutes. Like before, we will use the “substring” function with a condition statement to determine what to return:

    concat(substring(concat(substring-before(../my:ElapsedTime, ":"), ":", substring-after(../my:ElapsedTime, ":")), 1, (string-length(substring-after(../my:ElapsedTime, ":")) = 2) * string-length(concat(substring-before(../my:ElapsedTime, ":"), ":", substring-after(../my:ElapsedTime, ":")))), substring(concat(substring-before(../my:ElapsedTime, ":"), ":0", substring-after(../my:ElapsedTime, ":")), 1, (string-length(substring-after(../my:ElapsedTime, ":")) = 1) * string-length(concat(substring-before(../my:ElapsedTime, ":"), ":0", substring-after(../my:ElapsedTime, ":")))))

    Step 4: Create the TotalTime expression for keeping a running total of the elapsed time

    The last step is to create the TotalTime expression – this is similar to the ActualTime expression except we now incorporate the “sum” function to get the running total:

    concat(substring(concat((sum(../my:group1/my:group2/my:TotalMinutes) - sum(../my:group1/my:group2/my:TotalMinutes) mod 60) div 60, ":", sum(../my:group1/my:group2/my:TotalMinutes) mod 60), 1, (sum(../my:group1/my:group2/my:TotalMinutes) mod 60 > 9) * string-length(concat((sum(../my:group1/my:group2/my:TotalMinutes) - sum(../my:group1/my:group2/my:TotalMinutes) mod 60) div 60, ":", sum(../my:group1/my:group2/my:TotalMinutes) mod 60))), substring(concat((sum(../my:group1/my:group2/my:TotalMinutes) - sum(../my:group1/my:group2/my:TotalMinutes) mod 60) div 60, ":0", sum(../my:group1/my:group2/my:TotalMinutes) mod 60), 1, (sum(../my:group1/my:group2/my:TotalMinutes) mod 60 < 10) * string-length(concat((sum(../my:group1/my:group2/my:TotalMinutes) - sum(../my:group1/my:group2/my:TotalMinutes) mod 60) div 60, ":0", sum(../my:group1/my:group2/my:TotalMinutes) mod 60))))

    Step 5: Test!
    Enter a Start and End Time in the form of: h:mm AM(PM), such as: 8:00 AM and 5:00 PM – the ActualTime field should display the difference (as 9:00) and if you continue adding rows, the TotalTime field should reflect the running total.

    This functionality allows you to create elapsed time scenarios that work in both client and browser forms without writing one line of code!

    Scott Heim
    Support Engineer

  • Microsoft InfoPath 2010

    Calculating new, default date and time values

    • 2 Comments

    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:
            Days
            Hours
            Minutes
    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

  • Microsoft InfoPath 2010

    InfoPath Team is Hiring Program Managers

    • 0 Comments

    If you’re reading this blog, you’re probably passionate about InfoPath. You built several InfoPath applications, and think the technology has lots of potential. But you also realize that InfoPath is still a fairly new product, so there’s a lot to be done to realize this potential into customer value.

    Why not take your passion to the next level? InfoPath is gearing up for vNext, and now is a perfect time to influence your favorite XML form designer from the inside. Come work for the InfoPath Team!

    We’re looking for experienced Program Managers to help define the next, revolutionary wave of InfoPath client and Forms Services.

    We have three positions open:

    1) Programmability PM: seeking individual familiar with programmability and/or enterprise development who is passionate about making InfoPath easier and more powerful for developers. Formal job description coming soon.

    2) Forms Services PM: define and drive the v2 of Forms Services. Are you passionate about XML and AJAX technologies? If so, this position is for you.

    3) Program Manager who will help us make it easier to create and use electronic forms and integrate them into business applications.

    Please submit your resumes to our staffing consultant, Michael Ashe, at [micashe at microsoft]. Make sure you meet the minimum posted requirements before you apply.

  • Microsoft InfoPath 2010

    All you wanted to know about browser compatibility

    • 5 Comments

    These articles will help you answer many of the questions you might have about Forms Services browser compatibility, rich-client only features, and the Design Checker.

    Title

    Details

    Audience

    Plan browser support (OSS)

    Describes the different levels of browser support for MOSS.

    Admin

    Creating InfoPath Form Templates That Work With Forms Services

    Describes the following:

    1. Features supported by both InfoPath and Forms Services
    2. Features not supported by Forms Services
    3. Object Model that works in Both InfoPath and Forms Services
    4. Object Model that works only in InfoPath

    Dev

    Web browser compatibility in InfoPath Forms Services

    Describes the following:

    1. Which browsers are compatible with Forms Services?
    2. Which InfoPath 2007 features are supported in browser-enabled form templates?

    End-user

    InfoPath 2007 features that are unavailable in InfoPath Forms Services

    Describes the following:

    1. Controls that work in both InfoPath and Forms Services
    2. Controls that work only in InfoPath (lists Design Checker errors and messages)
    3. Features that work in both InfoPath and Forms Services
    4. Features that work only in InfoPath (lists Design Checker errors and messages)

    End-user

    Microsoft Office server system requirements

    Describes system requirements for all server products, including browser requirements.

    All

     

    Anneliese
    Senior Writer

  • Microsoft InfoPath 2010

    Forms Services and multiple IIS Web Applications

    • 1 Comments

    We often get questions asking if the XmlFormView control can be used in a particular environment. Usually you will use it on a regular page that belongs to a WSS Site or on a page in _layouts folder of a WSS site. These scenarios are supported and covered in the following MSDN article on the XmlFormView control at http://msdn2.microsoft.com/en-us/library/ms778201.aspx. If you want to create an IIS application inside of your WSS site, hosting XmlFormView on the pages of this site is not supported (and actually does not work properly).


    How you can get into this unsupported state

    In Visual Studio, you create New -> ”Web Site” inside http://myWSSserver/_layouts. Then follow the steps to host an XmlFormView control on one of the pages. You add a SubmitToHost handler to the XmlFormView control on your hosting page. When viewing the form, everything seems to be working fine until a post back to the host happens. You either get no results or the “submitted successfully” dialog without your hosted page’s handler called.


    Why it does not work (so you don’t try to use XmlFormView in this way)

    Here are two things that contribute to the issue:

    1. XmlFormView control uses a helper page which is located in the _layouts folder. This page handles AJAX post backs from the control. Every post back that the control makes by itself will be handled by that page. This page can also request that the hosting page performs a full page post back (i.e. for Submit to host). In this case, the Form Services code in the browser will call submit on the page which will then be directed to the original hosting page code for processing.

    2. Forms Services uses the ASP.Net session state to store all of the information about the current document. The ASP.Net session state data is not shared across IIS applications even if the ASP.Net session cookies are the same.

    Let’s combine these two facts with the fact that the “Web Site” that you just create under _layouts is in a different IIS web application than _layouts itself. You have the main page (i.e. _layouts/myWebSite/MyHostingPage.aspx) in one IIS web application but the Forms Services’ post back page (_layouts/postback.aspx) is in a different (default WSS) application.

    From reason 1 above, we can see that most of requests will go to the _layouts/postback.aspx page. Based on reason 2, we will get one Session State data blob for all post backs going to the postback.aspx page (since it goes to the same application). This Session State data blob will contain information about the document you are editing including all changes you are making in the browser.

    When the request needs to go to the hosting page (i.e. when the post back page detects a call to the SubmitToHost handler) then another Session State data blob will be created for these requests (even if they share an ASP.Net session cookie, the request goes to a different application). This new Session State data blob does not have information about the document that was created and edited during the calls to postback.aspx.

    At this point, there are two unrelated Session State data blobs which are holding data about part of your editing session. As you can guess, neither of them contains complete information. Depending on what pieces of editing went to each copy of your Session State data blobs, you can get unexpected behavior after the post back. Often the Forms Services’ code will detect a complete mismatch between the data in the Session State and the information from the browser. It will end up starting a new document to get to a consistent state.


    How to fix it

    Note that the steps below will change your site from living in a separate application to sharing the same application as WSS. Pease make sure that you understand effect of this change (and check if you need a separate application in the first place).

    1. Run IIS Manager (i.e. Start->Run->inetmgr).
    2. In the IIS Manager, chose the web site (in the left pane) where you created the web site in Visual Studio (shown in figure 1).
    3. Right click on the selected web site, choose “Properties”, and on the “Virtual Directory” tab, click the “Remove” button next to “Application name” (shown in figure 3).

    Following image highlights what icon you should see next to supported (green) and unsupported (red) folders:

    Setting on Property page for the folder where hosting of XmlFormView will work properly:

    Here is sample of properties where hosting will be broken. Click Remove button to fix it. Again, note that you need to understand effect of it for your application:

    Alexei Levenkov, Nicholas Lovell, and Balbir Singh
    Software Design Engineers

  • Microsoft InfoPath 2010

    UDC File Authoring Tool

    • 6 Comments

    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

    InfoPath-Related Blogs: OPML Compilation

    • 4 Comments

    We promised, and here it is: the OPML compilation of RSS feeds of bloggers that write about InfoPath. Just download the file and import it into your favorite news aggregator.

    Sneak peek:

    Cheers!
    Alex

Page 4 of 12 (298 items) «23456»