I should also point out that I know the difference between a metaphor and simile in case that was bothering you from the opening sentence.
I am nothing if not a masterful linguist after a beer or two or more.
Damon gives just one example of a poisoned dagger in the game of Sharepoint Development: The Item Event Receiver.
I’m usually disappointed when writers employ oft-overused metaphors to describe a situation.
Hopefully you know about item event receiver if you are having problems with them firing twice.
If not, kudos to you for tackling the object model with reckless abandon.
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.
What this means is that you cannot store data in instance-level variables and share that data between event handlers.
You could think that the current values are stored in the Before Properties of the item but that’s not true: the Before Properties are unreliable at this point. When the name of the planet is changed, the update is canceled and an error message is returned to the user.
If the name isn’t changed, the changes are saved to the Share Point list.
To prevent users from changing the name of the planet, you can develop a Item Updating event receiver.
This event occurs before the data is saved to the Share Point list.