Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>As Chris Gray said, one use is to signal when something has happened that your code didn't directly call. The most common cause here is probably user actions on the GUI. Another example might be an asynchronous operation completing on another thread.</p> <p>The other reason to use events is when you don't know who might be interested in what has just happened. The class raising the event doesn't need to know (at design time) anything about how many instances of what other classes might be interested.</p> <pre><code>class Raiser { public DoSomething() { //Do something long winded. OnDidSomething(new DidSomethingEventArgs()); } public EventHandler&lt;DidSomethingEventArgs&gt; DidSomething; private OnDidSomething(DidSomethingEventArgs e) { if (DidSomething != null) DidSomething(this, e); } } </code></pre> <p>Obviously, you also need to define the DidSomethingEventArgs class which passes on the relevant data about the event. This also illustrates a common naming convention for events. If the event is called X, then the event is only ever raised in a method called OnX and any data it passes on is an instance of class XEventArgs. Note that an event can be null if no listeners are subscribed to it, hence the check just before we raise the event.</p> <p>Note that this class knows nothing about what other classes might be interested in the fact that it did something. It simply announces the fact that it has done it.</p> <p>Multiple classes can then listen out for the event:</p> <pre><code>class ListenerA { private Raiser r; ListenerA(Raiser r) { this.r = r; r.DidSomething += R_DidSomething; } R_DidSomething(object sender, DidSomethingEventArgs e) { //Do something with the result. } } </code></pre> <p>And:</p> <pre><code>class ListenerB { private Raiser r; ListenerB(Raiser r) { this.r = r; r.DidSomething += R_DidSomething; } R_DidSomething(object sender, DidSomethingEventArgs e) { //Do something with the result. } } </code></pre> <p>Now, when the DoSomething method is called on the Raiser instance, all instances of ListenerA and ListenerB will be informed via the DidSomething event. Note that the listener classes could easily be in different assemblies to the raiser. They need a reference back to the raiser's assembly but it doesn't need a reference to its listeners' assemblies.</p> <p>Note that the above simple Raiser example may cause you some problems in a multi-threaded program. A more robust example would use something like:</p> <pre><code>class Raiser { public DoSomething() { //Do something long winded. OnDidSomething(new DidSomethingEventArgs()); } #region DidSomething Event private object _DidSomethingLock = new object(); private EventHandler&lt;DidSomethingEventArgs&gt; _DidSomething; public EventHandler&lt;DidSomethingEventArgs&gt; DidSomething { add { lock(_DidSomethinglock) _DidSomething += value; } remove { lock(_DidSomethinglock) _DidSomething -= value; } } OnDidSomething(DidSomethingEventArgs e) { EventHandler&lt;DidSomethingEventArgs&gt; handler; lock (_DidSomethingLock) handler = _DidSomething; if (handler == null) return; try { DidSomething(this, e); } catch (Exception ex) { //Do something with the exception } } #endregion } </code></pre> <p>This ensures that another thread adding or removing a listener while you are in the middle of raising the event doesn't cause problems.</p> <p>The simple listeners used here will also cause memory leaks if instances of the listener classes are being created and destroyed. This is because the Raiser instance gets passed (and stores) a reference to each listener as they subscribe to the event. This is enough to prevent the garbage collector from properly tidying up the listeners when all explicit references to them are removed. The best way round this is probably to make the listeners implement the IDisposable interface and to unsubscribe from the events in the Dispose method. Then you just need to remember to call the Dispose method.</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload