C# pattern to prevent an event handler hooked twice


How about just removing the event first with -= , if it is not found an exception is not thrown

/// -= Removes the event if it has been already added, this prevents multiple firing of the event
((System.Windows.Forms.WebBrowser)sender).Document.Click -= new System.Windows.Forms.HtmlElementEventHandler(testii);
((System.Windows.Forms.WebBrowser)sender).Document.Click += new System.Windows.Forms.HtmlElementEventHandler(testii);

This question already has an answer here:

Duplicate of: How to ensure an event is only subscribed to once and Has an event handler already been added?

I have a singleton that provides some service and my classes hook into some events on it, sometimes a class is hooking twice to the event and then gets called twice. I'm looking for a classical way to prevent this from happening. somehow I need to check if I've already hooked to this event...

Microsoft's Reactive Extensions (Rx) framework can also be used to do "subscribe only once".

Given a mouse event foo.Clicked, here's how to subscribe and receive only a single invocation:

Observable.FromEvent<MouseEventArgs>(foo, "Clicked")


private void MyHandler(IEvent<MouseEventArgs> eventInfo)
   // This will be called just once!
   var sender = eventInfo.Sender;
   var args = eventInfo.EventArgs;

In addition to providing "subscribe once" functionality, the RX approach offers the ability to compose events together or filter events. It's quite nifty.

have your singleton object check it's list of who it notifies and only call once if duplicated. Alternatively if possible reject event attachment request.

You really should handle this at the sink level and not the source level. That is, don't prescribe event handler logic at the event source - leave that to the handlers (the sinks) themselves.

As the developer of a service, who are you to say that sinks can only register once? What if they want to register twice for some reason? And if you are trying to correct bugs in the sinks by modifying the source, it's again a good reason for correcting these issues at the sink-level.

I'm sure you have your reasons; an event source for which duplicate sinks are illegal is not unfathomable. But perhaps you should consider an alternate architecture that leaves the semantics of an event intact.