SharePoint PeopleEditor.ResolvedEntities always zero when control is disabled

I’ve been trying to track down this mystery in a project I’m working on for some time.

In a nutshell, we’re using the Microsoft.SharePoint.WebControls.PeopleEditor/picker for resolving SharePoint users in our custom web parts like any good SharePoint dev might want to do.  We collect the user data and various other important stuff, and save our data to a database. We later pull up a page with this same part, edit some data, and update our entries in the database.  Everything is working just great.

Except, sometimes it appears that the User ID’s we’re saving for the users in the people editors are getting lost, but only SOMETIMES.  I would see it, then not be able to reproduce it and move on with other important matters and place it on the backburner.

So let’s start with some code samples of what’s going on.

This section of code is what we use to get the SPUser.ID from the PeopleEditor/Picker before saving it to the database (IF a user is selected of course).

int primaryContactID =0;

if (PrimaryContactEditor.ResolvedEntities.Count > 0); 
{
  Microsoft.SharePoint.WebControls.PickerEntity entity = 
    (Microsoft.SharePoint.WebControls.PickerEntity)PrimaryContactEditor.ResolvedEntities[0];
  acctName = entity.EntityData["AccountName"].ToString();
  SPUser user = SPContext.Current.Web.EnsureUser(acctName);
  primaryContactID = user.ID;
}

When the part is loaded, we load up the editor to show the user as being preselected.

    
private void PopulatePickerControl(Microsoft.SharePoint.WebControls.PeopleEditor pe, int userID)
{
   if (userID > 0)
   {
       SPSecurity.RunWithElevatedPrivileges(delegate()
       {
           SPUser user = 
             SPContext.Current.Web.SiteUsers.GetByID(userID);
           Microsoft.SharePoint.WebControls.PickerEntity entity = 
             new Microsoft.SharePoint.WebControls.PickerEntity();
           entity.Key = user.LoginName;
           entity = pe.ValidateEntity(entity);
           if (entity != null)
           {
               System.Collections.ArrayList list = new System.Collections.ArrayList();
               list.Add(entity);
               pe.UpdateEntities(list);
           }
       });
  }
}

Pretty straight forward stuff. and everything works perfectly.  The same code to get the users account, ensure they are placed into the web, and the ID is retrieved works flawlessly every single time.

Until…

The PeopleEditor is disabled to prevent editing.

And we’ve got good reasons for doing so.  In this case, some users should never be able to change the users selected from the people editors/pickers.  At this point, they are merely there for presentation purposes, but some users can. And those  users may need to change the value.

But, if you set the editor to disabled such as this:

PrimaryContactEditor.Enabled = false;

  

Then the ResolvedEntites array will always be zero.  The editor will surely show you’re resolved entities, but this collection will always be empty.

Why? I have no idea.  It makes no sense to me why it should behave this way.

– Keith

3 thoughts on “SharePoint PeopleEditor.ResolvedEntities always zero when control is disabled

  1. Must be frustrating. A while ago I had something similar with an InfoPath form looking up the user through web service call. When the control was disabled it wouldn’t save the value. Apparently when on the client side a blur event occured (like enter and lose focus of the field) it worked. I think that some piece of nifty javascript saves the state of the control. Not sure if this helps in your case though. 🙂

  2. I not sure if this will help but every time fill resolve is called FillClaimsForEntity is also called, at least when using claims based authentication. Here’s a link that might be of help if you haven’t already read the article.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s