BeforeProperties and AfterProperties

2012-11-212014-11-30 Andy BurnsEvent Receivers, SP2007 Development, SP2010 Development, SPItemEventReceiverLeave a comment

I am sick of having to hunt down the link to Synergy’s post on the BeforeProperties and AfterProperties available in different events on SPListItems. For my reference, here it is:

List:

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

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

Note: Allegedly, this does change if the event receiver is synchronous – the before properties are available. I’ve not checked this out yet.

Obviously, for SharePoint 2007 systems that doesn’t apply – as ‘*ed’ event receivers are always asynchronous.

Delete Event Receiver from a Content Type with Code

2012-10-102014-11-30 Andy BurnsContent Type, Event Receivers, SP2010 Development, SPContentType, SPItemEventReceiverLeave a comment

SharePoint allows you to attach event receivers to content types. That’s pretty handy. Unfortunately, deleting event receivers from those content types is much more hard. Perhaps this is why the Document ID feature fails to remove the content types that it adds. However, here is one possible approach.

SPContentType ctype = site.RootWeb.ContentTypes[SPBuiltInContentTypeId.Document];
if (ctype != null)
{
 if (ctype.EventReceivers != null)
 {
   bool bContinueDelete = true;
   while (bContinueDelete)
   {
     if (ctype.EventReceivers.Count < 1)
     {
       bContinueDelete = false;
     }
     else
     {
     bool bFoundOne = false;
     foreach (SPEventReceiverDefinition d in ctype.EventReceivers)
     {
         //Could match on the Type of the event receiver, but for this example, let's use name
         if (d.Name.Contains("Document ID"))
         {
           d.Delete();
           ctype.Update(true, false);
           bFoundOne = true;
           break;
         }
     }
     if (!bFoundOne)
     {
       bContinueDelete = false;
     }
   }
 }
}

More on why this is important in a later post.

How DisableEventFiring / EventFiringEnabled works

2011-01-052014-11-30 Andy BurnsEvent Receivers, Reflection, SP2007 Development, SP2010 Development, SPItemEventReceiver6 Comments

I’ve got an event handler on a SharePoint list that’s fairly long running, and this then raised a question in the office – do these settings control event firing for the currently running event handler, or for the entire list?

Very often you see lines of code like this…

this.EventFiringEnabled = false;
item.Update();
this.EventFiringEnabled = true;

… but was this really necessary? Are people worried about events not being handled ‘cos firing is disabled, or is this just a convenient way of tracking whether events are enabled or not? Continue reading “How DisableEventFiring / EventFiringEnabled works” →

Registering EventHandlers against ContentTypes

2010-04-282014-11-30 Andy BurnsEvent Receivers, SP2007 Development, SPContentType, SPFeatureReceiver, SPItemEventReceiver7 Comments

In SharePoint, Event Handlers (or Event Receivers – whichever terminology, a child of SPItemEventReceiver) can be registered against lists/libraries. You can do this through an SPWeb (site) scoped feature, declaratively or programmatically with an SPEventReceiverDefinition.

Unfortunately, you can’t declaratively register event receivers at the SPSite (Site collection) level – which would be fantastic – just turn on the feature and across all your site collection lists/libraries of a give type would get additional event receivers. Personally, I think this may be a bug; I don’t see why this shouldn’t work at the SPSite level.

Anyway, there is still another option – we could register our event against a particular Content Type. This is a less often used approach, which raises two questions – how do you do it, and what happens to child Content Types? Continue reading “Registering EventHandlers against ContentTypes” →

Event Properties AfterProperties – what should they be?

2009-09-022014-11-30 Andy BurnsDevelopment, SPField, SPFieldCollection, SPItemEventReceiverLeave a comment

While working on pre-filling ListItem fields on an item, I became a bit puzzled. The SPItemEventProperties.AfterProperties collection is a dictionary which can contain the named value for one of the fields of the item. In other words, if we wanted to set a value “Tax Area” to “Europe” we’d do:

properties.AfterProperties["Tax Area"] = "Europe";

In our case, however, we didn’t know what these properties were before hand. Rather, we were ‘inheriting’ values from a parent folder. Thus, we were going to use the parent folder’s SPField object for each field to define the value. I started out using:

properties.AfterProperties[parentField.Title] = parentItem[parentField.id];

But is Title the right property to use? Well, having looked through a number of blog posts, this seems to be the subject of some confusion.

At first Title is okay to use. However, you can change the display name of the field. For example, we could change our field’s Title to ‘Tax Region’ – but we still need to use ‘Tax Area’ in our AfterProperties collection.

So, InternalName is the right property of the SPField to use – but there is a hiccup. The InternalName is encoded – Tax_x0020_Area – so you have to unescape it like I’ve talked about before.

The summary is, then, use the unescaped InternalName in your AfterProperties collection.

Pre-filling fields on EditForm.aspx

2009-08-252014-11-30 Andy BurnsItemAdded, ItemAdding, SP2007 Development, SPItemEventReceiver7 Comments

I’ve just been looking at an interesting problem that a colleague has had. We’ve a customer who wants to ‘inherit’ metadata values from Folders in a SharePoint Document Library to Documents uploaded to within it. For example, if the Folder has column ‘Case ID’, they want the value of the ‘Case ID’ column of any Document within it to be automatically set to the same value. And another twist – we won’t know the columns beforehand.

The problem is, they want this value to be pre-populated before the EditForm.aspx page is displayed.

Here, for example, the Case ID is autopopulated from the parent folder. So, what’s the best way of doing that? Continue reading “Pre-filling fields on EditForm.aspx” →

Andy Burns' Blog

Whatever I'm working on

SPItemEventReceiver