Microsoft InfoPath 2010
The official blog of the Microsoft InfoPath team

May, 2010

  • Microsoft InfoPath 2010

    SharePoint List Data Connections in InfoPath 2010

    • 30 Comments

    Hi, my name is Joey Wiggs and I’m a developer on the InfoPath team. In InfoPath 2010, one of the ways in which we've improved our integration with SharePoint Server 2010 is by providing richer capabilities for connecting to and getting data from SharePoint lists. In this post, I will compare SharePoint list data connections in InfoPath 2007 and InfoPath 2010, and discuss the benefits of using the new 2010 data connection type. I will also outline the steps required to upgrade your InfoPath 2007 SharePoint list data connections to the new and improved version.

    About SharePoint List Data Connections

    Let’s start by looking at a scenario when you would use a SharePoint list data connection in an InfoPath form.

    In Microsoft, when employees run into technical issues, they log a help ticket by filling out an InfoPath form. They start filling out the form by selecting an Problem category from a dropdown list. We could store the category names inside the form but that means that whenever a category is added, deleted or renamed, the form will need to be updated.

    Help Request Form

    Instead, we can store the Category names in a separate SharePoint list and pull this information into the form when users are filling it out. We can do this by adding a SharePoint list data connection to the form. The benefit of using a data connection is that the data can be maintained separately in a single location and the form will always pull in the most up to date information from that location.

    Why use the 2010 SharePoint List Data Connection?

    In InfoPath 2010, we have extended the functionality of the SharePoint list data connection.
    • Query fields are now supported
    • Additional field types are supported
    • The data pulled from the SharePoint list is no longer tied to the default list view in SharePoint

    Query Fields

    Setting a query field value allows you to filter the data before it is pulled into the form. SharePoint list connections in InfoPath 2010 now have query fields, allowing you to filter your data and return more scoped results. You can query on a number of different field types, including single lines of text, numbers, and even people and lookups. By filtering your list connections, you can ensure only the data you want is brought into your form. This can also speed up your form connection, as it may pull in less data than it would otherwise.

    For example: By setting the “Modified by” query field to the current user (using the username() function), the query will return only those list items that were modified by the current user.

    Fields Task Pane

    Additional Field Types

    In 2007 the list connection could only support simple field types, such as single lines of text, currency fields, and single choices. The new connection now also supports complex field types such as multiple choices, multiple lookups, attachments and person fields.

    Sorting results

    In previous releases, the number of items returned and the sorting order of said items were determined by the default view for the list in SharePoint. To work around this limitation, form designers had to go to the list settings page in SharePoint and modify the default list view to get the data they wanted into their forms. That’s no longer the case! The new 2010 list data connection will return all of the items in the list, regardless of the default view’s settings. You can also sort the incoming data by a particular field in the data connection wizard when creating a new connection, or modifying an existing one.

    Data Connection Wizard

    How can I get this in my forms?

    If you’re designing a new InfoPath 2010 form, you just need to add a SharePoint list data connection and you’ll have this functionality available to you from the start.

    The new list features are supported in InfoPath 2010 filler and browser forms only, so if you want to use the new connection in your existing InfoPath 2007 form you will need to upgrade your existing forms to InfoPath 2010. However, once upgraded, InfoPath 2007 clients will not be able to open the form.

    To upgrade the data connection, form designers must complete the following steps:

    1. Use the data connections dialog to upgrade the list connection
    2. Rebind your controls, rules and code
    3. Save the form as an InfoPath Web Browser Form Template or InfoPath Filler Form Template

    Data Connection Wizard

    Convert Data Connection to Current Version

    For each list data connection that retrieves data in your form, you will need to select it in the data connections dialog and press the “Convert to Current Version” button. You will be prompted if you want to continue. After conversion, you will see an information bar when that connection is selected stating that the data connection is incompatible with the current version of your form. That’s okay; we’ll be upgrading the form to the required version later.

    Data Connection Wizard

    Rebind Controls and Fix up Rules and Code

    After converting a data connection, you’ll need to rebind your controls and fix any field or XPath references inside rules and code. When rebinding, you’ll need to rebind the repeating sections to the d:SharePointListItem_RW group, then rebind the controls inside the repeating sections to the correct fields. You can rebind a control by selecting it, then right-clicking and choosing “Change Binding”. This brings up a dialog where you can choose what field or group to bind the control to.

    Control Binding

    Fixing your rules consists of finding the rule and updating any field references. Field references from the old adapter will look something like “@Title” after you convert your 2007 adapter to 2010. Select the reference, pick the field you want the rule to reference and away you go.

    Rule Fix up
    You can tell that the rule actually references the field by how it looks. If the field reference has a namespace, an @ symbol, or a full XPath then that rule won’t work and needs to be fixed.

    Save the Form

    Finally, you’ll want to save your form as an InfoPath form template (filler or web browser depending on your needs). Note that if you try to save it before converting the data connections, the design checker will prevent you from doing so. 2007 list data connections cannot be in a 2010 form, and 2010 list data connections cannot be in a 2007 form. There’s no mixing and matching, and the design checker will prevent you from saving the form unless they’re correct.

    Once you’ve saved your form, you will be able to avail of all the capabilities of the new 2010 SharePoint list data connection. At any time, you can use the data connections dialog to modify the newly upgraded connection, to add new field types, or to use the sort by functionality. You can also set the value of query fields using rules in your form.


    Enjoy!

    Joey Wiggs

    InfoPath Developer

  • Microsoft InfoPath 2010

    Cool Forms! Task Form

    • 8 Comments

    This week’s cool form was submitted by Sean Cantellay of Cantellay Consulting. The form allows the user to select a SharePoint task from the right and view it in the form on the page. The task has been broken up into four views and the tab buttons moves the user through the different views. The user can also Escalate the task to another SharePoint group by clicking the Escalate button and selecting the group.

    Click on images for larger pictures.

    ViewTwo

    ViewThree

    ViewFour

    EsclateView

    If you have a “cool” form that you would like to share with us, please send an e-mail with the following details to coolform@microsoft.com -

    • Attach 1 or 2 screenshots of your form
    • Provide a brief description of the form
    • You may also attach the XSN file (optional)

    The most popular submissions will be featured on our blog in future posts.

    Check out other Cool Forms here.

  • Microsoft InfoPath 2010

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

    • 7 Comments

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

    In this post:

    Data Validation

    Special behavior in SharePoint List Forms

    Removing Blank Default Values

    Example Usage:

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

    Multi-select list box

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

    Data validation

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

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

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

    Multi-select list box Properties

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

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

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

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

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

    Technical Details

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

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

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

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

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

    Multi-select list box

    Technical Details

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

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

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


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

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

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

    Multi-select list box

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

    Multi-select list box

    Advanced Information:

    Special behavior in customized SharePoint list forms

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

    SharePoint Column Settings

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

    Removing Blank Default values

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

    Multi-select list box

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

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

      Edit Default Values

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

    Multi-select list box

    Frank Mueller
    InfoPath Developer

  • Microsoft InfoPath 2010

    Cool Forms! Feature Status

    • 6 Comments

    This week’s cool form is a form used to track the status of testing of feature areas. One interesting decision made in this form is to use questions as labels rather than field names. This makes the form much easier to understand, particularly given that field names for compactness in the list view tend to be only one or two words. Another key aspect of this form design is the use of ‘?’ picture buttons beside certain questions. Clicking one of these buttons provides detailed help text underneath the question. You can see an example of this text in the screenshot in blue. This technique of hiding detailed text until the user asks for it enables the form designer to get the best of both worlds, a form that is compact and easy to read as well as a form that provides enough detail to ensure it is filled out correctly.

    Feature Status Form

    If you have a “cool” form that you would like to share with us, please send an e-mail with the following details to coolform@microsoft.com -

    • Attach 1 or 2 screenshots of your form
    • Provide a brief description of the form
    • You may also attach the XSN file (optional)

    The most popular submissions will be featured on our blog in future posts.

    Check out other Cool Forms here.

  • Microsoft InfoPath 2010

    Take a list offline using SharePoint Workspace 2010

    • 5 Comments

    In this short video demo, Shirish Pulikkal from the InfoPath test team shows how you can customize a SharePoint list in InfoPath designer and work with the list offline in SharePoint Workspace.

    The Scenario: A fictitious company Fabrikam wants to track assets in their lab using SharePoint list. They want to be able to track assets both in the online and offline case. Fabrikam has decided to use InfoPath to customize the list and SharePoint workspace to enable working offline with the list.

    The Process: We start by customizing the form for the SharePoint list in InfoPath designer and add a secondary data connection to pull data from another SharePoint list. Then we publish the form back to the SharePoint list and sync it in SharePoint Workspace. Now we can create list items while working offline in SharePoint Workspace and items can be synced to SharePoint server when we get back online.

    Get Microsoft Silverlight

  • Microsoft InfoPath 2010

    Free InfoPath 2010 Web Cast: Best Practices in Form Design

    • 3 Comments

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

    You can sign up for this free Web cast on https://www.eventbuilder.com/event_desc.asp?p_event=a2d1f10w.

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

    Academy Live

  • Microsoft InfoPath 2010

    Create a Rating Control using Picture Buttons

    • 3 Comments

    In this short video demo, Matt Bielich from the InfoPath test team shows how you can add a rating control to your InfoPath 2010 forms using picture buttons.

    Get Microsoft Silverlight
Page 1 of 1 (7 items)