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.
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.
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.
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.
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.
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:
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.
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.
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.
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.
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.
If you have a “cool” form that you would like to share with us, please send an e-mail with the following details to email@example.com -
The most popular submissions will be featured on our blog in future posts.
Check out other Cool Forms here.
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.
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.
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.
Special behavior in SharePoint List Forms
Removing Blank Default Values
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.
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.
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.
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.
If you select a blank custom value, an asterisk will appear in the top right hand corner of the custom value text 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.
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.
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.
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. 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.
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.
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.
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.
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.
If you wish there to be no default selection at all in the control, you need to remove the default value node.
Frank Mueller InfoPath Developer
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:
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.