Click here to visit the DevSource C# Center where you'll find great C# articles and information!

Events are an integral part of .NET programming. This is true not only for Windows Forms programs, but also ASP.NET applications and console mode utilities. Applications obtain control messages through events and use events to implement callbacks--synchronous or asynchronous--in much the same way C callback functions are used in traditional Windows programming. You can't get far in .NET programming without a good understanding of the event programming model.

Events Programming Overview

Although you don't have to, I strongly recommended that you follow the .NET coding conventions for naming your events and event handling functions. If you don't follow the conventions, it becomes difficult for others to understand what your code is doing. Because the .NET Framework is written using the conventions and all the documentation assumes that you will be using the same conventions, the line between requirement and recommendation blurs.

1. Following the conventions, if you wanted to create an alarm event for your class, you would do the following:
2. Create a class derived from EventArgs that holds the event data. By convention, you would call this AlarmEventArgs.
3. Declare a delegate, called AlarmEventHandler. (A delegate is an object that specifies a member function, and, optionally, a particular object containing the member function.)
4. Define a public event member, Alarm in your class, and set the type of the event member to the event delegate type. That is: public Event AlarmEventHandler Alarm;
5. Define a protected method in your class that raises the event (that is, calls the function stored in the delegate). By convention, the name of this method would be OnAlarm.
6. When your code needs to raise the event, you create an AlarmEventArgs object instance and call OnAlarm.

   All of this is well-documented in the .NET SDK documentation. I've included the pertinent sample code below for illustration.

   // 1. The AlarmEventArgs class
   public class AlarmEventArgs : EventArgs 
   {
      private readonly int nrings = 0;
      private readonly bool snoozePressed = false;
      
      //Properties.
      public string AlarmText {  
         ...
      }
      public int NumRings {
         ...
      }
      public bool SnoozePressed{
         ...
      }
   }
   
   // 2. The AlarmEventHandler delegate
   public delegate void AlarmEventHandler(object sender, AlarmEventArgs e);
   
   // 3. The Alarm event in the custom class
   // 4. The protected OnAlarm method that raises the event
   // 5. Raising the event in the Start method
   public class AlarmClock 
   {
       ...
       public event AlarmHandler Alarm;
       protected virtual void OnAlarm(AlarmEventArgs e)
       {
         if (Alarm != null) 
             Alarm(this, e); 
       }
   
       public void Start()
       {
           ...
           System.Threading.Thread.Sleep(300);
           AlarmEventArgs e = new AlarmEventArgs(false, 0);
           OnAlarm(e);
       }
   }
   

   This code looks complicated, but after you've written a few classes that have custom events, the technique becomes second nature. And in most cases that's all you have to know about implementing events. The event model is simple, clean, and quite efficient at dispatching. However, if your class has many events it can start to take a lot of memory.

   Using the normal event programming model, each event that you define requires a delegate to store the event information. This memory is allocated for each instance of the class, regardless of whether any handlers are actually attached to the delegate. The Alarm event in the class above will always have memory allocated for the delegate. This isn't a problem in most cases because most of the classes you create will only have a few events defined. Even if you create many instances of those classes, the impact on memory usage will be minimal.

   However, consider System.Windows.Forms.Control, which defines almost 70 events, and all of the classes that inherit from it that define even more. Multiply 70 events by the dozens (potentially hundreds) of controls in a typical Windows Forms application, taking into account that most of those events don't have any attached handlers, and you can see the potential for wasting huge amounts of memory for event delegates that are never used.

   Next: ' Conserving Memory ' >>

   
   
   
   

   Discuss Event Properties in C#   >>> Be the FIRST to comment on this article!

   
   
   

   >>> More Using Microsoft Visual Studio Articles          >>> More By Jim Mischel