Search This Blog

Thursday, 20 December 2012

BeforeProperties and AfterProperties on SPItemEventReceiver

Yes, most of them forget or don't remember the values for BeforeProperties and AfterProperties on SPItemEventReceiver like me. Already so many posts available for this, but i would like to consolidate some of the posts which i read.
Post 1 : SynergyOnline
    In this post Randy Williams, provided clear explanation about this. Some basic details about Event Receivers got from this post

Event receivers are a great way to hook into various SharePoint events.  These can apply to Feature events such as FeatureActivated, List events such as FieldAdded, and many others.  The most common set of receivers used, however, are part of SPItemEventReceiver which let you wire your code up to a number of events that can occur to items on a list or library.

When working with events, you’ll quickly find that before (synchronous) and after (asynchronous) events exist, and the method suffix such as “ing” (e.g. ItemAdding) and “ed” (e.g. ItemAdded) will tell you whether it gets invoked before or after the actual change is made.  Basic stuff.

Comparison table of Before and After properties in SPEventReceiver for list and document library

List BeforeProperties AfterProperties properties.ListItem
ItemAdding No value New value Null
ItemAdded No value New value New value
ItemUpdating No value Changed value Original value
ItemUpdated No value Changed value Changed value
ItemDeleting No value No value Original value
ItemDeleted No value No value Null
No value means that column value in the hash table was not available. 
New value means that the correct value for the column was available. 
Changed value means that the correct updated value was available.
Original value means that the correct original value was available.

Here is the same test against a document library:
Library BeforeProperties AfterProperties properties.ListItem
ItemAdding No value No value Null
ItemAdded No value No value New value
ItemUpdating Original value Changed value Original value
ItemUpdated Original value Changed value Changed value
ItemDeleting No value No value Original value
ItemDeleted No value No value Null

Here Randy Williams  denoted BeforeProperties of SPEventReceiver contains "No Value" for lists. Also given explanation for that. So its good and I got better idea of how before and after events work for both lists and libraries from this post.

But i didn't stop my analyze on this, i continue with few more posts, then i identified following post

Post 2 : http://www.sharepointalex.co.uk/index.php/2010/06/beforepropertiesafterproperties-in-event-receivers-i-always-forget-this/
    Note : This is untested one, check at your end once before implementing in production.
    In this post Alex, also referred SynergyOnline post.But i got something different and more important thing about the Item Updating event from the comment given by Ray Proffitt, he given some more interesting thing about SPEventReceivers in http://blog.ray1.net/2011/06/getting-beforeproperties-and.html
   here he introduced a new option to us, which is defining Synchronization property in the elements.xml file of event receiver solution.

Points to be noted:

Anyway the proper way of doing things is real simple, and I stumbled upon it using Powershell to check my event receivers.

SPEventReceiverDefinition has a Synchronization property.

An Asynchronous event passes the objects to another thread and you lose the BeforeProperties and AfterProperties.
A Synchronous event keeps the thread and you can access the BeforeProperties and AfterProperties.

In my case after specifying the event receiver as Synchronous I was able to compare existing values with values in properties.AfterProperties on an Receiver Type = ItemUpdating.

So to set a Receiver as Synchronous, just add Synchronous to your definition (elements.xml) or in code set the Synchronization property.

Eg:
<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
    <Receivers>
         <Receiver> ... ...
             <Synchronization>Synchronous</Synchronization>
        </Receiver>
    </Receivers>
</Elements>

Conclusion : In our Software Development world, everything has limitation at the same time everything is possible, the only thing required is good analyses. I am also running on the track to analyze things good.

Hope this helps people like me !!!!!!!!!!

No comments:

Post a Comment