I’m usually disappointed when writers employ oft-overused metaphors to describe a situation.With that in mind, Share Point 2010 is like a sea of icebergs – there is a lot going on under the surface that you may not notice until it’s too late.:) Got the solution at last, doing to much of searching and stretching my mind :).
You can think of an item event receiver like a database trigger: it has different events that fire during the course of Share Point running an operation on a list item (or document item).
Item Event Receivers derive from the SPItem Event Receiver class and have a number of methods that can be overridden to respond to various events: As you look through this list, you should notice that events have two types of endings: WARNING: One major gotcha you should know about the SPItem Event Receiver class is that while you can implement multiple list item event handlers in a single class, Share Point instantiates a new instance of that class for each individual event it needs to handle.
If you choose to participate, the online survey will be presented to you when you leave the Technet Web site.
Developing a Sharepoint application would have all the fun of a video game, if only you had infinite lives.
This property bag is perfect for storing "system" or temporary stuff, you will never want your users to see.
Yes you could create a field for that, but the OP asked about sharing a value between code fragments, no need for a field there. Instead of creating "current Item" (and doing a "Get Item By Id" lookup/Query), why didn't you just use "properties. I just want to make sure this was an oversight and I am not missing something.
Remember its a Sand Box solution approach for event receivers, not for farm solution.
Microsoft is conducting an online survey to understand your opinion of the Technet Web site.
Unfortunately, that makes your project like the Titanic.
I don’t mean that it’s largest and most luxurious application every written, but rather that you may be cruising headlong into a nasty rendezvous with an iceberg that could deal a severe blow to your project.
We may never know about all of the dangers lurking out there, but today we’re going to cover at least one danger you may encounter while writing event receivers – an annoying issue with the Item Updating and Item Updated events firing twice.