You can use this approach - create class:
public class DisabledItemEventsScope : SPItemEventReceiver, IDisposable
private readonly bool oldValue;
oldValue = EventFiringEnabled;
EventFiringEnabled = false;
#region IDisposable Members
public void Dispose()
If the feature scope is set to Site, then the ListUrl and the ListTemplateId is ignored, and then it will fire on all events for all lists.
Fix it by putting your eventreceiver in a web-scoped feature.
Form MSDN : SPEventReceiverBase.DisableEventFiring Method
Prevents events from being raised.
So someone could think that all events are disabled (all items, all events, all receivers).
But: How DisableEventFiring / EventFiringEnabled works
The setting (DisableEventFiring in 2007 and EventFiringEnabled in
2010) must be for the current event handler; ...
We faced the same problem at work recently. And there are two good options here we've found:
1. Global variable
Use SPWeb.Properties or some other SharePoint property bag, and use kind of "global variable" trick: you set this variable to "ON" before the batch is executed, and set it to "OFF" later when the batch is finished. And in your event receivers, ...
So, after a few weeks on and off trying to figure this one out, having no luck with any replies on any forum, I just thought I would have a look at how the UI page was doing this. (Why didn't I think of this earlier?!)
That's when the property EnableMetadataPromotion showed up.
Having this keyword to search for, it didn't take me long to google the missing ...
As a short answer, There is no Event Receiver type that will trigger when opening a Library/ List Page!!!
The Event receiver should be used to trigger a specific action before or after a specific event like Item Added (After), Item Adding (Before), Item updated (After), Item updating (Before) ...etc
The alternative solution:
Creating a web part that will ...
With the help of MS support, we finally got to the bottom of this issue. It turned out to be related to the content database upgrade (from MOSS 2007 to 2010) that had taken place months before. Ultimately, there was no object model fix for the problem, and the SharePoint product group ended up giving us permission (and code) to modify the content database ...
I ran into a similar situation, you can try following things.
Check the element.xml file. If you have changed the name space of the project ..you would have to make the relevant changes in the element.xml file <Class>NameSpace.ProjectName</Class>
If you are targeting this event recivier to a specific list, then make sure that you have the url ...
I anticipate that your root list has the same event receiver assigned to it, and that causes the recursion.
The problem, of course, may be not so obvious, but anyway, to prevent event receiver to fire several times, there is a common practice in SharePoint: just use DisableEventFiring and EnableEventFiring methods.
internal void UpdateItemOnRootwebList(...
With SP2010, You can use ItemAdded with Synchronization (instead of ItemAdding) to perform some operations
after the item is created but before it is presented to the user.
Then you can use if(properties.ListItem.File!=null)to determine if listitem has file associated with it.
To make ItemAdded synchronous, you need to set the Synchronization property ...
Usually in Page_Load or in CreateChildControls you should place the check for IsPostback and load the data only if the page is not in the postback mode. And also, you should load the data in all postback handlers.
This way, the data is loaded always and only once per page load.
But while this solution will work perfectly for a separated page, things get ...
An event receiver runs in the same process as the code that triggered it. This can be anything running SharePoint code:
If the action (adding an item, updating an item...) is performed by an end-user, from the browser UI, the code that actually performs the operation runs under W3WP (the IIS application pool process, i.e. the one that runs the Web ...
welcome to SharePoint Stack Exchange!!
It is not possible out of the box, just so that you know!
But, your problem was so interesting that I thought of spending couple of hours just to develop a small customization :)
So this is how my solution works:
The default size of images posted on Newsfeed time-line is 300x300px
I developed a custom feature that ...
You might be able to differentiate by knowing Content Type of the item being added. You can get Content Type by accessing properties.AfterProperties["ContentTypeId"]
As documented here, Document Content Type ID starts with 0x0101 vs Folder's content type id - 0x0120
So your code may look like:
SPContentTypeId itemContentType = new SPContentTypeId(...
Navigate to corresponding Elements.xml, and you will notice Receivers element with ListTemplateId attribute, like this:
What you need is to use ListUrl attribute instead, and point it to the specific list using provided url.
There is a how-to on this on MSDN:
You have to do following:
properties.RedirectUrl = properties.Web.ServerRelativeUrl +
properties.Status = SPEventReceiverStatus.CancelWithRedirectUrl;
properties.Cancel = true;
properties.ErrorMessage = "File extension not allowed here";
properties.Status = SPEventReceiverStatus.CancelWithError;
Your discussion intrigued me and I decided to test it eventually :)
I wrote 4 event receivers - ReceiverS1, ReceiverS2, ReceiverA1, ReceiverA2, sync (seq num 100), sync (seq num 101), async (seq num 100), async (seq num 101) accordingly. I added receivers and verified using sharepoint manager that all settings correct. This is code for receivers:
Ouch! Are you trying to use Word Interop in an event receiver! You should not! This will instantiate Word (the actual application) on the server side and this is a really scary and bad operation! Just don't do it! It's not even supported, but that's not the issue here - you server will eventually fail miserably...
Now, on to how to do it! Converting from ...
For a list Deleted event we cannot get any values. Is it possible to change your code in Item Deleting Event?
For more information on List Item Events, please go through the below urls
I've always had to handle the concurrency issues. On SP 2010, I've done these things:
1) Set the Synchronization property of your receiver to SPEventReceiverSynchronization.Synchronous.
2) Disable event firing within the receiver methods e.g. this.EventFiringEnabled = false;
3) When working with Properties.ListItem object, check if it's not null before ...
Might want to take a look at this article
Basically, what your looking for is something like this
You basically have to create a custom SPWebEventReceiver and activate your mandatory feature under "WebProvisioned" method, like this:
public class YourWebEventReceiver : SPWebEventReceiver
public override void WebProvisioned(SPWebEventProperties properties)
// Activate your mandatory ...
By design ListAdded can be hosted by SPWeb or SPSite only as documented here. So Feature Stapling cannot be avoided if you want to enforce that across the farm.
As per MSDN Documentation, If the Receivers tag has no ListTemplateId or ListUrl attribute, the event receiver is registered at the same scope as the Feature. Which means you should not use ...
An Event Receiver is managed code that responds to SharePoint Foundation events whenever specific triggering actions occur - which is same as Event Handler.
The term "Event Receiver" is specific to context of SharePoint where as "Event handler" is a general term used for any subroutine that handles inputs received in a program.
Event handlers are a central ...
This is caused by a race condition in the version control system. Events are as follows:
1. Your file finished uploading
2. Your event handler code runs (in a different thread)
3. The update list item form is populated and displayed
4. You click OK in the update list item form and the changes are submitted
Since ItemAdded is asynchronous, sometimes your ...
SharePoint 2010 RTM'd in April 2010. That article is from December 2009, when it was in beta. We're now into SP1, so it wouldn't surprise me if they changed the dispatcher to use w3wp.exe instead of owstimer.exe.
Personally, if you know that it runs under either of the two, debug either until you hit breakpoints. I don't reckon it's that much of a deal.
When set through the UI, workflows can only act on the following events: ItemAdded, ItemUpdated. (You can also start workflows manually)
What you want is to block the ItemDeleting event. The "ing" ending implies your trap occurs before the event, not after, which would be pointless in your case.
So, what you want is an event receiver on the ItemDeleting ...
The order of the events if pretty clear (ItemAdding – ItemAdded – ItemUpdating – ItemUpdated, and others e.g. when you delete, emailReceived, WorkflowStarted, etc.), but how many there are triggered could differ depending on the application (e.g. WebUI, Word document Save as, and more important - custom implementations!).
E.g. while working on properties ...
There are custom events for incoming emails, have you looked for "Email events"? If you add such Event Receiver you might have to handle the item correctly as well, or else it will not be inserted properly.
public class OnEmail : SPEmailEventReceiver
public override void EmailReceived(SPList list, SPEmailMessage emailMessage, String ...