Archive for the tag 'SPItemEventReceiver'

Registering EventHandlers against ContentTypes

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? Read more »

Event Properties AfterProperties – what should they be?

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

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.

AutoPopulated Field

Here, for example, the Case ID is autopopulated from the parent folder. So, what’s the best way of doing that? Read more »

 Subscribe in a reader