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):
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”;
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.