Gizz quoted his supplier:
You should only ever add/remove an event handler once in most applications. It is not designed by Microsoft to have event handlers added and removed continuously as a method to controlling these things.
Well, I don't know about adding/removing event handlers "continuously," but I see nothing wrong with changing event handlers more than once. I've been exploring flow-based programming lately and have been experimenting with using events/delegates as a means of realizing it. So I have no problem with adding/removing event handlers several times during the lifetime of an application as a means of controlling the flow of a program (or whatever). In fact, I think it's a pretty cool approach.
Gizz continued to quote his supplier:
This is because an event handler is usually dealt with in another thread (or how else could it be generated for the application)
If you're receiving event notifications from another thread, then thread-safety is an issue to be concerned about. but that has nothing to do with this:
and adding/removing notifications to the other thread can easily be the subject of racetrack timing errors.
Adding and removing event handlers to an event is thread safe. When compiling a field-like event, the compiler automatically creates storage to hold the delegate and creates accessors for the event that add or remove event handlers to the delegate field. To be thread-safe, the addition or removal operations are done while holding the lock on the containing object for an instance event or the type object for a static event. The C# Programming Language - 10.7.1 As far as firing an event, see Charlie Williams' reponse. There is a thread safety issue there. -- modified at 15:10 Monday 21st November, 2005
