Contact Selector the Good and the Bad

This week I was working on an InfoPath solution that required the use of the Contact Selector Control that is included with InfoPath, basically this is an Active X control that you can use as a way of selecting accounts that exist on your SharePoint server (for more info on the control and how to set it up check out this post from the InfoPath team blog) Now there is a standing rule that Active X controls don’t work in form services however this control is the exception to that rule and can be used in a browser enabled form. This being said there are some pit falls to keep in mind when using this control with managed code in a browser based deployment as you’ll see below.

While I didn’t have any trouble getting the control working I did have a requirement where by I needed to limit the number of contacts selected to 1. Now on the post noted above it is recommended to use the following code on the Validating event of the controls container group to add an error to the forms error collection hence preventing the user from submitting the form before continuing.

if (e.Operation == XmlOperation.Insert)

{

if (e.Site.SelectChildren(XPathNodeType.Element).Count > 1)

{

      e.ReportError(e.Site, false, Message, “Only 1 user can be selected!”);

}

}

This code worked great in the client version of the form however when I ran the browser version of the form, I found that this code would not run reliably.

If I entered 2 surnames to validate lets say “Smith” and “Jones” then clicked the validate button  the names would be resolved from the server and the control would be updated accordingly. However it seemed that the validation code had not run as there was no error being displayed. If I clicked the validate button  a second time the error would then be displayed. From what I could tell the form was either not posting back to the server correctly or the web version of the form wasn’t being refreshed. As there is no option to force the control to post back to the server. This meant I could end up with a validation error on the form that wasn’t visible to the user but would prevent the from submitting back to the server.

With my first attempt shot down for the time being I decided to take another approach, and add the following code to the Changed Event of the containing group that would remove all existing person records that didn’t exist at Index 1.

if (e.Operation == XmlOperation.Insert)

{

for (int i = e.Site.SelectChildren(XPathNodeType.Element).Count; i >= e.Site.SelectChildren(XPathNodeType.Element).Count && i > 1; i–)

{

       e.Site.SelectSingleNode(“./my:Person[” + i + “]”, this.NamespaceManager).DeleteSelf();

}

}

This code worked pretty well in the client version of the form as well, however once I deployed the form to Form Services I started getting errors from Form Services when I tried to Validate the entered contact or add a contact via the Select button.

Finally with both ideas giving me headaches and not much time left on the project clock I decided to remove my validation code, and email the InfoPath team and see if they had any ideas. Luckily in this circumstance this was not a big issue, as I was using the Contact Selector control as an routing input for a workflow so only the first contact in the control would be used. It would be nice to get a resolution to this though.

The Good

• Great way to get login based contact information in your form especially when that data is used in a workflow scenario
• Works in both the client and browser based solutions
• When used in a client based solution custom code can be added to validate the number of contacts selected

The Bad

• Can be a little precious about event code when used in a browser based deployment
• No out of the box way to limit the number of contacts selected
• No way to force the control to post back in a browser based deployment which means the validation errors and underlying data source can get out of sync