Advances in .NET Event Handling

class EventServer
{

public delegate void MethodInvokedDelegate();
public delegate void PropertyChangedDelegate();
public event MethodInvokedDelegate MethodInvoked;
public event PropertyChangedDelegate PropertyChanged;

public void DoWork()
{
if (MethodInvoked != null)
MethodInvoked();
}
public int Value
{
get
{
return _value;
}
set
{
if (_value != value)
{
_value = value;
if (PropertyChanged != null)
PropertyChanged();
}
}
}

private int _value;

}

Now suppose that we have an event handler for the MethodInvoked event. From that event handler we just wish to change the value of the property that in turn raises the PropertyChanged event. Here is the code for these operations:

static void MethodInvokedHandler(object sender)
{
EventServer srv = (EventServer)sender;
srv.Value += 2;
}

static void Main(string[] args)
{
EventServer srv = new EventServer();
srv.MethodInvoked += new EventServer.MethodInvokedDelegate(MethodInvokedHandler);
srv.DoWork();
}

These objects, when the application is running, operate in a very predictable way and there should be nothing suspicious about the two events. But let's introduce a third object, that audits events on its own, and that is oblivious of presence of the first event handler:

class Auditor
{
private void AuditMethodInvoked(object sender)
{
Console.WriteLine("MethodInvoked");
}
private void AuditPropertyChanged(object sender)
{
Console.WriteLine("PropertyChanged");
}
public Auditor(EventServer srv)
{
srv.MethodInvoked += new EventServer.MethodInvokedDelegate(AuditMethodInvoked);
srv.PropertyChanged += new EventServer.PropertyChangedDelegate(AuditPropertyChanged);
}
}

In this way we have simply allowed an auditor to subscribe to all events of the monitored object and to log their occurrences. But then one might be surprised to see that PropertyChanged event is logged before MethodInvoked event. Why is this so? The answer becomes clear if we carefully draw out the sequence of operations in this program:

1. EventServer instantiated

2. MethodInvokedHandler subscribed to MethodInvoked event

3. Auditor instantiated
   

   • AuditMethodInvoked subscribed to MethodInvoked event (after MethodInvokedHandler in invocation list)
   • AuditPropertyChanged subscribed to PropertyChanged event
     

4. DoWork invoked from code
   

   • DoWork raises MethodInvoked event that invokes subscribed handlers in order of their subscriptions
     
     ->MethodInvokedHandler invoked; makes change to property value, that causes recursive raising of PropertyChanged event
     
     ->AuditPropertyChanged handler invoked; prints "PropertyChanged" on output
     
   • MethodInvokedHandler completes execution; next handler in invocation list is invoked
   • AuditMethodInvoked handler invoked; prints "MethodInvoked" on output

Now it is obvious that an auditor's handler for PropertyChanged event executes before its MethodInvoked event handler. This is a simple consequence of the event execution model in .NET Framework.

One way to ensure that auditor is notified about events in their proper order is to ensure that auditor is the first one to subscribe to all monitored events in the system. In our example, that would be done like this:

EventServer srv = new EventServer();
Auditor a = new Auditor(srv);

srv.MethodInvoked += new EventServer.MethodInvokedDelegate(MethodInvokedHandler);
srv.DoWork();

Now everything works fine; the MethodInvoked event is logged first, followed by the PropertyChanged event. Unfortunately, this is rarely achievable in practice as we often do not control the code that instantiates child objects, as to subscribe to their events on first sight. But even if we can subscribe auditor before other handlers, the entire idea may fail if the application handles events in the form of overridden base class methods and a base class method is called at the end of the handler as in this example:

class CustomForm : Form
{
protected override void OnSizeChanged(EventArgs e)
{
DoWork();
base.OnSizeChanged(e);
}
}

Such implementation can be treated as bad design, since base implementation should be called first, and only then functionality should be added. But this kind of code may interfere with the auditor, preventing it from observing events in their correct order. Hence this solution remains applicable in general case only when it is required to know that specific event has occurred, rather than to know that it has occurred before or after some other event.

Conclusion

In this article we have shown several concepts and solutions applied in event driven applications. Emphasis remains on suggestion to program and maintain event handlers carefully. If there is interference between handlers, then it should be managed by carefully applying designs that help avoid unintentional data corruption and similar problems.

This topic is covered further in the following article titled How to Change Order of Event Handlers Execution at Run Time (http://www.c-sharpcorner.com/UploadFile/b81385/8741/), that explores implementation of multicast delegates. Note that multicast delegates are the core implementation used by the .NET Framework to invoke subscribed event handlers, although they are normally not observable by the code that subscribes to an event. Please refer to that article for a deeper analysis of event implementation internals in .NET applications.