Problems with "AfterProperties" in list event receivers

This is to summarize the inconsistent behaviors I encountered when working with "AfterProperties" in "ItemUpdating" event handler on a custom SharePoint list in SP 2010.

1) AfterProperties will be NULL when ItemUpdating event is called because of a code-update to list:

This is something that is not documented, and lead me into a lot of trouble:

Consider this scenario:

My SharePoint list had a column named "Email".

I wrote an "item-updating" event handler that will update a few other child lists with updated Email, when it was altered in the parent list..(to which the event handler was attached)

Here is the code:

string oldEmail = (properties.ListItem["Email"] == null) ? "" : properties.ListItem["Email"].ToString();

string newEmail = (properties.AfterProperties["Email"] == null) ? "" : properties.AfterProperties["Email"].ToString();

if(oldEmail != newEmail )

{

     //Update the other child lists with "newEmail"

}

I tested this code by editing the list item and updating the Email and the change was correctly propagated to  the other lists. 

After a few days we noticed that a lot of items in those child lists, had empty email values.

Reason:

When the item in parent list is edited directly using the SharePoint interface, then both properties.ListItem["Email"] and properties.AfterProperties["Email"] has the expected values.

But, when the list is being updated by code, and the code does not update the "Email" (for example, the code just updates "First Name" in the list)  then properties.AfterProperties["Email"] will be NULL in the event receiver code. AfterProperties will have the correct value, only when Email is also updated through code.

This was not the case when editing was done through SharePoint UI.( i.e If I edit that item and change only the "First Name", then AfterProperties["Email"] had the correct value..)

Because of this my event receiver had reset Email in all the child lists with empty values.

Resolution:

Unfortunately, the only resolution available was to check whether "AfterProperties" is NULL and in that case assume that the list item is updated through code somewhere else, and do nothing..

2) Dealing with "Lookup" columns:

If you are handling a "Lookup" column using "AfterProperties", then be careful. It looks like a bug where "AfterProperties" contains only the "ID" part of look-up and not the whole look-up value.

Consider this example, where I am checking whether a look up column value has been altered:

SPFieldLookupValue oldLookupValue = new SPFieldLookupValue(properties.ListItem["LookupColumn"].ToString());

SPFieldLookupValue newLookupValue = new SPFieldLookupValue(properties.AfterProperties["LookupColumn"].ToString());

if(oldLookupValue != newLookupValue)
{
     //look up column value has changed
}

The above code looks correct, but simply would not work in "ItemUpdating" event.

Reason:

Value of properties.ListItem["LookupColumn"].ToString() will have the correct look up value like "3;#karthik", but the value of properties.AfterProperties["LookupColumn"].ToString() will have only "3" (just the look up ID).

Resolution:

Here is the workaround that I implemented to get around this issue:

string oldLookupValue = (properties.ListItem["LookupColumn"] == null) ? "" : properties.ListItem["LookupColumn"].ToString();

string newLookupValue = (properties.AfterProperties["LookupColumn"] == null) ? "" : properties.AfterProperties["LookupColumn"].ToString();

int oldLookupID = 0;
int newLookupID = 0;

if (!string.IsNullOrEmpty(oldLookupValue))//Get the old Lookup id
{
     SPFieldLookupValue oldLookup = new SPFieldLookupValue(oldLookupValue);      oldLookupID = oldLookup.LookupId;

}
if (!string.IsNullOrEmpty(newLookupValue))//Get the new Lookup id
{
     newLookupID = Convert.ToInt32(newLookupValue);
}

if (oldLookupID != newLookupID)//Lookup has been updated
{     //value has changed

}

Another solution would be to use string parsing methods to compare just the ID part.

Event receiver, item permissions and form submission error

I had to open a SharePoint list for anonymous users to add items. The solution was to allow anonymous users to have "add" permissions on the list, design an InfoPath form for them to add the data, and fire an event receiver on the item added event to remove permissions for anonymous users on the item.. (In our case, anonymous users should not be able to see any item that was added to this list).

When I implemented this solution, InfoPath form would throw the error "Item was not found" after form submission. However the item was added successfully and the event receiver had also done its job.

Reason
The reason is pretty obvious. The event receiver had fired immediately after the item was added and removed all permissions on the list item, before InfoPath could complete its work. So, I thought delaying the event receiver by 10 seconds or so using "Thread.Sleep" would solve the issue. But that was not the case. I also observed a strange behavior where the InfoPath form itself waited for 10 seconds before throwing the same error again.

Resolution
The resolution was to execute the event receiver code in a separate thread as shown below:


         public override void ItemAdded(SPItemEventProperties properties)
        {
            EventFiringEnabled = false;
            try
            {
                Thread setPermissionsOnItem = new Thread(RunCodeInThread);
                setPermissionsOnItem.Start(properties);
            }
            catch (Exception ex)
            {
                //Log exception here
            }
            EventFiringEnabled = true;
        }

        private void RunCodeInThread(object objProperties)
        {
            Thread.Sleep(10 * 1000); //Halt for 10 secs to allow infopath form to complete
            try
            {
                SPItemEventProperties properties = (SPItemEventProperties)objProperties;
                // do the event receiver job here
            }
            catch (Exception ex)
            {
                //Log exception here
            }
        }

This solved the problem. The InfoPath form completed its processing immediately and the event receiver also worked fine. (A delay of 10 seconds is too much in most cases. You can reduce it considerably, but be sure to test it. I tried executing this code, without using Thread.Sleep and it worked 8 out of 10 times on an average)