SP Event Recievers Firing 10 Times On Purpose?

I don’t know whether it is, or if it isn’t by design, and I am curious of if this was any sort of business applicability to have the event reciever architecture make you manually disable and enable event firing for certain events. What I am talking about is, if you have a simple event receiver, say something that is doing the manipulation of a list item object name, you have to compensate accordingly in your code, otherwise the event will occur ten times (we are even going to go into system updating so that metadata is enforced, which will be the subject of a separate post) by placing a SPEventReceiverBase.DisableEventFiring Method(), inserting your updating code consuming the properties argument, then terminating with the SPEventReceiverBase.EnableEventFiring Method() method (obviously you don’t have to fully qualify the methods in code since you can just reference the class with the “this” qualifier). This basically just breaks down to disabling event firing temporarily before you execute your custom code, and then once your code is done doing it stuff, you renable event firing.

The code could be as simple as this in your ItemUpdated Method (this isn’t production worthy code, you should place site context references into using constructs otherwise to take advantage of appropriately disposing of objects. Furthermore, it is usually better to just extract a method that is representative of your code, since then it is much easier to wrap and increases the readability of the code):

[csharp]

public override void ItemUpdated(SPItemEventProperties properties)

{
SPSite oCurSite = new SPSite(“http://h4v0kTeSt”);
SPWeb oCurWeb = oCurSite.RootWeb;
SPList oCurList = oCurWeb.Lists[“testing event receiver”];
SPListItem oCurItem = oCurList.GetItemById(ID);
oCurItem[“Title”] = “adjusted name”;
oCurItem.Update();
}

[/csharp]

But this adjusted it ten times (I put a trace listener on it), so if the event receiver was something that was actually doing something that could affect business operations, I would have to wrap my changes with the Disable and Enable event firing code.
So, why is this necessary?

When looking under the hood at some of the programmatic architecture of it, it appears that there is basically filtering of an infinite list before handing the result of the output, therefore there are continuous triggers which occur and trigger the eventĀ  receiver in a loop. But, I am unsure where the magical number of 10 comes up, or how it only executes 10 times, since it looks like it should be an infinite number of executions occurring.

I would be interested in more insight regarding it.

Share

EventArgs Example

In one my past posts, I talked about that CryptoCollaboration using the EventArgs base class because it keeps things nice and generalized, allowing for expanasion for the handling of future event integration. A person emailed me and asked for a practical example of when would use such a thing in a SharePoint WebPart. Eh, ok.

I am going to use an example of a progress class, that, well, as you can guess will display the progress of some sort of execution that happens with a SharePoint WebPart.

The first class is the Process Arguments class (ProcessArgs), that inherits from the EventArgs base class.

[csharp]

public class ProgressArgs : EventArgs
{
private int m_nPercentageComplete = 0;
private DataRow m_oDataRow;

public ProgressArgs(DataRow dataRow, int percentageComplete)
{
this.m_oDataRow = dataRow;
this.m_nPercentageComplete = percentageComplete;
}

public DataRow CurrentDataRow
{
get
{
return this.m_oDataRow;
}
}

public int PercentageComplete
{
get
{
return this.m_nPercentageComplete;
}
}
}

[/csharp]

In the next class, there will be the establishment of the event handler that will be called from a sister class by use of a delegate.

[csharp]

public delegate void ProgressEventHandler(object sender, ProgressArgs e);

[/csharp]

Now that the delegate is established, you can call it in some general class file.

[csharp]

public event ProgressEventHandler ProgressEvent;

protected virtual void OnProgress(ProgressArgs e)
{
if (this.ProgressEvent != null)
{
this.ProgressEvent(this, e);
}
}

[/csharp]

Then calculate out the progress.

[csharp]

ProgressArgs e = new ProgressArgs(row, (int) ((((double) num) / ((double) this.DBDataTable.Rows.Count)) * 100));
this.OnProgress(e);

[/csharp]

I am not saying that this is the only way to do it, but with applications that you plan on extending later it is the route that I have choosen to go in the past. I may at some point explore the deficiencies in a such an approach, however at this current time I just want to finish the damn thing.

Share