What kind of situations I'd need to use events of C#

Question

Hi,

I am studying events in C# but there are not much articles or information that show me where or what kinda position I'd need to use events in.

Could some one give me real world example that makes them more understandable.

Thanks in advance.

Answer 1

Let's say you are developing a UI. You create a widget and you add it to the main form. When something happens in your widget, you can use events to trigger some action on the form - disabling other buttons, etc.

Just like how a button's click event works.

Answer 2

The most practical example I generally see is User Interactivity. Let's use a Button as a specific example. When the button is clicked, you obviously want something to happen. Let's say we call "SaveSettings()". However, we don't want to hard-code "SaveSettings()" into the button. The buttom would be commanding SaveSettings() to occur. Obviously, this prevents the button from being reusable - we can't use a button which calls SaveSettings() anywhere but the settings dialog. To avoid writing the same button code for every button, each one calling a different function, we use an event.

Instead of the button calling a function directly, the button announces that it has been clicked. From there, the button's responsibility is over. Other code can listen for that announcement, or event, and do something specific.

So in our SaveSettings example, the settings dialog code finds the "OK" button and listens for its "I got clicked" announcement, and when it is fired, calls SaveSettings().

Events can become very powerful because any number of different listeners can wait for the same event. Many things can be invoked by the event.

Answer 3

Sure thing. think of an event as the notification that occurs when something completes in the system that your code didn’t directly call. In C# it's really easy to get code to run when an event "fires"

For example when a user presses a button an event will be raised or when a background network operation completes. In C# you use the += semantics to attach to the event that will be “signaled” when the event fires.

I made you a simple C# winforms program – in it I added a button using the Visual Studio “Designer” (I just dragged a button from the Toolbox to the Window).

You’ll see the line “button1.Click” – in this case I want to do something when the “Click” event is raised.

using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Linq;
using System.Text;
using System.Windows.Forms;

namespace events
{
    public partial class Form1 : Form
    {
        public Form1()
        {
            InitializeComponent();
            button1.Click += new EventHandler(button1_Click);
        }

        void button1_Click(object sender, EventArgs e)
        {
            MessageBox.Show("Hi!");
        }
    }
}

You’ll also see other kinds of events in practice for example:

• Network operation has completed (WebClient.DownloadFileCompleted)
• User Interfaces (resizing windows for example)
• Timers (set off the timer in 10 minutes)

Answer 4

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.

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.

class Raiser {

   public DoSomething() {
      //Do something long winded.
      OnDidSomething(new DidSomethingEventArgs());
   }

   public EventHandler<DidSomethingEventArgs> DidSomething;

   private OnDidSomething(DidSomethingEventArgs e) {
      if (DidSomething != null)
         DidSomething(this, e);
   }
}

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.

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.

Multiple classes can then listen out for the event:

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.
   }
}

And:

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.
   }
}

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.

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:

class Raiser {

   public DoSomething() {
      //Do something long winded.
      OnDidSomething(new DidSomethingEventArgs());
   }

   #region DidSomething Event

   private object _DidSomethingLock = new object();
   private EventHandler<DidSomethingEventArgs> _DidSomething;

   public EventHandler<DidSomethingEventArgs> DidSomething {
      add { lock(_DidSomethinglock) _DidSomething += value; }
      remove { lock(_DidSomethinglock) _DidSomething -= value; }
   }

   OnDidSomething(DidSomethingEventArgs e) {
      EventHandler<DidSomethingEventArgs> handler;
      lock (_DidSomethingLock)
         handler = _DidSomething;
      if (handler == null)
         return;
      try {
         DidSomething(this, e);
      } catch (Exception ex) {
         //Do something with the exception
      }
   }

   #endregion
}

This ensures that another thread adding or removing a listener while you are in the middle of raising the event doesn't cause problems.

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.