InfoPath

Click here for the first post in this series, and visit us for SharePoint 2010 Training.

One thing you may notice between List and Library forms is that there are different controls available, and that Library forms have a superset of the controls available to List forms. The image below has the extra controls available in a Library form highlighted in blue.

Let’s start from the bottom and work our way up to explain why these are missing.

Containers

Everything missing here has to do with some sort of repeating element. Repeating elements don’t make any sense in a List form, as you can’t have some subset of your list columns have extra data in them. That’s just not how a list works. If you have columns that allow multiple selections, then you can certainly populate them individually with multiple-selection people pickers or check boxes.

But let’s say we want to have a list where we pick multiple people and multiple cars and remember who drives which car based on that information. It’s true that we wouldn’t be able to do this, but we couldn’t do it in a single SharePoint list anyhow. There is no cross-column relationship possible there, so even if we made sure to pick the same number of people as cars, we still wouldn’t know which car belonged to whom.

Note that if you create a list form that allows you to manage multiple list items with the same form, repeating containers are used by that form to handle that replication.

Objects

The only thing extra in this section is the file attachment control. In a library form you can have multiple attachments. You can do the same thing in a list form with the Attachment field, but only one of them is allowed. You can use it to upload multiple attachments, but you can’t have them in more than one section of the List form. In a library, you could have several different attachment controls in various locations.

Input

The first piece missing from the List forms is the option button. This is not to be confused with a radio button and is instead more like a checkbox. While it is possible to re-cast a drop down list box as an option button after the control has been added to the form, it won’t behave like you would expect. Don’t do this. Feel free to experiment, but it won’t behave in any way that you’ll want.

Next we’ll talk about the absent external data column. In a Form Library this allows you to choose from a Business Connectivity Services entity. In a list form, it’s not available. If you go ahead and add an External Data column to the list and reopen the form, the controls available for the columns populated by it will be merely lines of text with no actual link back to the entity. People could put in whatever text they want. I’m sure many of you can think of workarounds for this involving population of options from web services and so on, and those are legitimate solutions, but there is no direct mechanism to mimic that behavior.

Lastly, the bulleted, numbered, and plain lists are missing. Experiment by trying to convert a list box on the List form into one of them, and you’ll find that the behavior is not what you would expect. The basic premise is that that sort of entity does not really exist in a SharePoint List, and with no available analogue the controls have been removed.

Signing

You cannot digitally sign a list form. You can’t do it for a library form either, but you can instead sign sections of it. Putting everything into one section and signing that would be functionally equivalent to signing the entire form.

Conclusion

The general theme, aside from the external data issue, is that you’re missing controls because SharePoint Lists do not store all of the data types available in InfoPath forms. Just as Form Library forms are a subset of what is available in standard InfoPath forms, the List forms are a further subset of that.
Until next time, feel free to contact us for any of your SharePoint 2010 Training needs.

At Pilothouse, we do a lot of SharePoint Training, but in the course of a week long class there isn’t as much time to cover some of the topics as in-depth as we would like.

This is the first of a series of posts that will discuss many aspects of custom form creation with InfoPath. Here we’re giving a brief introduction to the what and some of the why behind these customizations, and in the next parts we will be digging a bit deeper to learn more about what you can and cannot do with this tool.

As with most things in SharePoint, some seemingly difficult things will become trivial, and some seemingly trivial things will become difficult or impractical. I don’t say impossible because when you know as much as some of us do about the product you can come up with custom-coded solutions to many of those impossible cases, but impractical is a fair term to throw around.

New in SharePoint 2010 is the ability to customize list forms with InfoPath Form Designer 2010. In SharePoint 2007 it was only possible to collect data from these forms with a form library (if you know how to get InfoPath form data into normal lists in SharePoint 2007 without custom code feel free to post your tricks – there are a few ways).

One of many issues with a form library is that it is not an actual list, but a document library. One implication is that you cannot set the item level permissions for the entire list to “view only your own items.” For surveys or other data collection tasks that would prefer individual data to not be shared with others, this was problematic. Yes, you could write a custom event receiver to change permissions on new items that have been added, but at the point where you want to start allowing modifications you have to think a little harder about what the receivers are doing and theoretically have more than one working in concert.

The first parts of this series will be addressing the following questions:

• When to use a list form vs a form library
• Differences in available controls between the two types of InfoPath forms
• Having different custom Edit, New, and View forms for the same list