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 buttonimage  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 image 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

7 thoughts on “Contact Selector the Good and the Bad”

  1. How did you get the contact selector to work in a browser based form? According to the InfoPath team, you can’t do this. I haven’t been able to do this either. What is your secret or your special magic? 🙂

  2. I used the Blog “Using the Contact Selector Control”. For some reason when I enter a surname using the Contact Selector it’s not found. I can create a lookup field in a custom list on my site that works fine. So I’m assuming that that connection to AD is setup ok. I’m not sure I have the custom data connection setup correctly. Or, Context.xml file setup correctly. I have: . I’ve tried “http://myserver”. The physical server “//server”. I saw a few other post, people having the same problem. Anyone have additional information on setting up the custome data connection correctly?

  3. Are there any alternatives? I know very well that sharepoint hosted infopath forms, even the forms services ones, can host the contact selector, but it’s still activeX and it still requires that the user have Office 2007 installed on their host. This makes the whole idea of the Infopath forms services (web-enabled) moot because you have to have the thick client anyway. I’m aware that the browser infopath forms can bind to a web service call, so if I want to select some users, say I bind to a web service that grabs them and you pick one. The real problem, and I have run into this, is that when you get a dropdown list with 1500+ items in it, people pick the wrong one, easily. So, is there anything we can do, using browser based infopath forms services forms to get some sort of two staged action going on to get a more customized, compatible lookup control created?

  4. But I WANT to use the complete list of names and not just the one from the contact selector to send mails … the “field” in my workflow only seems to work with 1 … is there some parsing magic I need to do to handle all the names for the “to” box in my email TO line?

Leave a Reply

Your email address will not be published. Required fields are marked *