Hot answers tagged event-receivers
IMO, the only correct handling of this problem would be to have only one VS project, building into one single WSP package. And also: one feature only. The feature that provisions files should be the one that deletes them at deactivation. It does not make sense to activate F01 and deactivate F02 to undo what F01 did! Furthermore, how F02 would be activated in ...
You're not alone! :) First, it is a very good point, IMO, to consider event receivers (ER) instead of workflows (WF) for your solution. WF are a heavy infrastructure, are complicated to use for end-users, do not migrate well, etc. On the opposite, ER are transparent to end-users, you control excatly what happens, they work the same on 1 or 1000 items, you ...
The problem turned out to be inside StartSomething: it was trying to update the very same item, upon which the OnItemUpdating had been fired. To solve a problem it is sometimes enough to write it down :)
Turned out I've handled the operation a little too late because it works only when handling the event ItemFileMoving not ItemFileMoved. It's as simple as that: properties.Cancel = true; because the ErrorMessage won't be displayed in Explorer. The default Windows error message looks like this:
Only top voted, non community-wiki answers of a minimum length are eligible