.Net Code Monkey RSS 2.0
 Friday, February 19, 2016
# Centralised Event Dispatcher in C# - Part 4
This is part four of a series of posts where I am going to share with you the solution I have used in a recent project for a centralised event dispatcher. All of the source code will be available in my public GitHub repositories. The concept I have tried to realise is a central class that can raise events for any listener to subscribe to.

In part one we created the event dispatcher class library.
In part two we consumed it from a windows forms application.
In part three we look at adding pooling for commonly raised events and implement an 'ApplicationEventPool'.

In this part we will were going to be looking at applying a restriction on what events can be safely pooled. However further investigation following feedback on the articles has indicated that there may be little to gain from pooling the events, so until a better reason presents itself to continue investigating pooling I am going to bring this series to a close here.

Friday, February 19, 2016 6:43:15 AM (GMT Standard Time, UTC+00:00)  #    Comments [0] -
.Net | C# | Event Dispatcher | Event Handling | Events
 Friday, February 12, 2016

Using ReSharper Tool to Create an Immutable Class

If you have the JetBrains ReSharper tool for Visual Studio it is a trivial task to create a whole immutable class from a single line constructing the object before a class representing the object even exists in your solution.

Process

Given the following line, and assuming that no class called `MessageEvent` already exists anywhere in your Visual Studio project solution.

var @event = new MessageEvent(sender, CreateMessageTextBox.Text);

Create a new class from the constructor call

Click on the `MessageEvent` constructor word. Observe the red reSharper light bulb in the left margin and mouse-over it. You will see a tool tip "Create type 'MessageEvent' (Alt + Enter)". Click the "Create type 'MessageEvent'" option and this will create a new class of this type in the current file. Select "class" or "struct", then tab through the constructor argument types and names, changing as required. Clear out the `throw new System.NotImplementedException();` from the constructor.

internal class MessageEvent
 {
     public MessageEvent(object sender, string text)
     {
             
     }
 }

Move the class to its own file

Click on the class type name, in this case `MessageEvent`, observer the reSharpoer hammer in the left margin and use the "Move to 'MessageEvent.cs'" to create the class in its own file. Using Visual Studio Solution Explorer, move the `MessageEvent.cs` to your preferred location.

Correct the class namespace

Click on the class namespace and use the ReSharper light bulb in the left margin to adjust the namespace to suit the location or correct it manually.

Introduce Fields for the Constructor Arguments

Click on each field and use the ReSharper light bulb in the left margin to "Introduce and initialize field"

internal class MessageEvent
 {
     private readonly object _sender;
     private readonly string _text;

     public MessageEvent(object sender, string text)
     {
         _sender = sender;
         _text = text;
     }
 }

Encapsulate field

Click on the field name and use the ReSharper light bulb in the left margin to "Encapsulate Field". Select the appropriate options, scope usage, etc, in this case I will just use "Read Usages".

internal class MessageEvent
 {
     private readonly object _sender;
     private readonly string _text;

     public MessageEvent(object sender, string text)
     {
         _sender = sender;
         _text = text;
     }

     public object Sender
     {
         get { return _sender; }
     }

     public string Text
     {
         get { return _text; }
     }
 }
And there you have it. An immutable class created with ease from a single constructor statement using ReSharper. Enjoy your new found productivity!

ReSharper Download

You can download a free 30 day trial of JetBrains ReSharper here.
Friday, February 12, 2016 5:35:10 AM (GMT Standard Time, UTC+00:00)  #    Comments [0] -
.Net | C# | CodeProject | Visual Studio 2012 | JetBrains ReSharper | Visual Studio | Productivity
 Thursday, February 11, 2016

Centralised Event Dispatcher in C# - Part 3

This is part three of a series of posts where I am going to share with you the solution I have used in a recent project for a centralised event dispatcher. All of the source code will be available in my public GitHub repositories. The concept I have tried to realise is a central class that can raise events for any listener to subscribe to.

In part one we created the event dispatcher class library, in part two we consumed it from a windows forms application. In this part we are going to look at pooling commonly raised events and implement an 'ApplicationEventPool'.

UPDATE: Please note that following feedback from others, and during the creation of part 4 the event pooling was not found to give much advantage, so you may wish not to read any further of this article.

Assumptions

It is assumed that the reader of this article already has a good understanding of coding with C#, can create projects and solutions, classes and Windows Forms, and can add references to a project and import references into a class. It is also assumed the reader understands basic inheritance and interface implementation.

So one of the issues with the solution we currently have is as the system grows the number of events being raised may grow astronomically, and if each event raised creates a new instance then a memory concious system may start to "sweat" especially if the event data is quite large.

With this in mind we can look to minimise this slightly by allowing the system to pool commonly used events.

Dibware.EventDispatcher.Core

So lets move back into the core class library and see if we can implement a system to pool some of the commonly used events.

First lets define the contract which we think we are going to need for an object that pools Application Events. In the `Contracts` folder we will create a new interface named `IApplicationEventPool`. We probably need a method to try to add an event, one to try and get an event, one to try and remove and event, and a last to remove all events.
public interface IApplicationEventPool
{
    bool TryAdd<TEvent>(TEvent @event) where TEvent : class, IApplicationEvent;
    bool TryGet<TEvent>(out TEvent @event) where TEvent : class, IApplicationEvent;
    bool TryRemove<TEvent>(out TEvent @event) where TEvent : class, IApplicationEvent;
    void Clear();
}
For a class which implements this contract:
* `TryAdd` should try and add an event to the backing store of the class if an event of that specified type does not exist.
* `TryGet` should retrieve an event of the specified type if one exists in the backing store
* `TryRemove` should remove an event of the specified type from the backing store if it exists.
* `RemoveAll` should remove all events from the backings store

So now we can create the implementation of the interface as the `ApplicationEventPool` class. This will require a backing store which will be a dictionary with the key which will be a `System.Type` and a value which will be of `IApplicationEvent`
public class ApplicationEventPool : IApplicationEventPool
    {
        private readonly Dictionary<Type, IApplicationEvent> _applicationEvents;

        public ApplicationEventPool()
        {
            _applicationEvents = new Dictionary<Type, IApplicationEvent>();
        }

        public bool TryAdd<TEvent>(TEvent @event) where TEvent : class, IApplicationEvent
        {
            if (@event == null) throw new ArgumentNullException("event");

            Type eventType = typeof(TEvent);
            if (_applicationEvents.ContainsKey(eventType)) return false;

            _applicationEvents.Add(eventType, @event);

            return true;
        }

        public bool TryGet<TEvent>(out TEvent @event) where TEvent : class, IApplicationEvent
        {
            Type eventType = typeof(TEvent);
            IApplicationEvent applicationEvent;
            @event = null;

            if (_applicationEvents.TryGetValue(eventType, out applicationEvent))
            {
                @event = applicationEvent as TEvent;
            }

            bool eventFound = (@event != null);
            return eventFound;
        }

        public bool TryRemove(Type eventType) //where TEvent : class, IApplicationEvent
        {
            throw new NotImplementedException();
        }

        public void Clear()
        {
            _applicationEvents.Clear();
        }
    }
PLEASE NOTE: A set of units tests for the above class can be found in the `ApplicationEventPoolTests` class of the `Dibware.EventDispatcher.Core.Tests` in the repository.

Now we have an ApplicationEventPoolObject lets switch back to the UI project and set up a scenario which could use it.

Dibware.EventDispatcher.UI

Lets add a new button to the main form and name it `HelloWorldButton` and give it the text of "Hello World!". Now create a button click handler for the new button. In the handler lets use the `ApplicationEventDispatcher` to raise a new event called `HelloWorldShouted`.
private void HelloWorldButton_Click(object sender, EventArgs e)
 {
     ApplicationEventDispatcher.Dispatch(new HelloWorldShouted());
 }
As we haven't got an event called `HelloWorldShouted`, we had better create one in the `Events` folder.
internal class HelloWorldShouted : IApplicationEvent
 {
     public string Message
     {
         get { return "Hello, you event driven world, you!"; }
     }
 }
Now we need to add a handler method to the main Form controller and wire it up and un-wire it in the `WireUpApplicationEventHandlers` and `UnwireApplicationEventHandlers` methods respectively.
protected override void UnwireApplicationEventHandlers()
 {
     ApplicationEventDispatcher.RemoveListener<HelloWorldShouted>(HandleHelloWorld);
     ApplicationEventDispatcher.RemoveListener<ProcessStarted>(HandleProcessStarted);
 }

 protected override sealed void WireUpApplicationEventHandlers()
 {
     ApplicationEventDispatcher.AddListener<HelloWorldShouted>(HandleHelloWorld);
     ApplicationEventDispatcher.AddListener<ProcessStarted>(HandleProcessStarted);
 }
Put a break point in the 'HelloWorldButton_Click' method of the `MainForm`, run the application and click the `HelloWorldButton` a few times. you will need to close the message box each time of course! You will likely notice that a new `HelloWorldShouted` event object is created each time. Each time this event is instantiated, it is exactly the same as the last, so this may be a good candidate for using our `ApplicationEventPool`. Lets have a look at implementing this.

In the `MainProcess` we will create a new private field of interface type `IApplicationEventPool` and initialise it in the constructor as the concrete class `ApplicationEventPool`. we will also pass a reference to the `MainFormController` via it's constructor as the interface `IApplicationEventPool`. This will allow us later to swap out the `ApplicationEventPool` for another should we want to for testing or enhancement purposes.
internal class MainProcess : ApplicationEventHandlingBase
 {
     private readonly MainFormController _mainFormController;
     private readonly IApplicationEventPool _applicationEventPool;

     public MainProcess(IApplicationEventDispatcher applicationEventDispatcher)
         : base(applicationEventDispatcher)
     {
         _applicationEventPool = new ApplicationEventPool();
         _mainFormController = new MainFormController(applicationEventDispatcher, _applicationEventPool);
     }
In the `MainFormController` we will cache the `IApplicationEventPool` before passing the reference on once more to the `MainForm`.
private readonly IApplicationEventPool _applicationEventPool;
private MainForm _mainForm;

public MainFormController(IApplicationEventDispatcher applicationEventDispatcher,
     IApplicationEventPool applicationEventPool)
     : base(applicationEventDispatcher)
 {

     _applicationEventPool = applicationEventPool;
     _mainForm = new MainForm(applicationEventDispatcher, applicationEventPool);

     WireUpApplicationEventHandlers();
 }
Finally in the `MainForm` we will cache the `IApplicationEventPool` once more so it can be access throughout the form code.
private readonly IApplicationEventPool _applicationEventPool;

 public MainForm(IApplicationEventDispatcher applicationEventDispatcher,
     IApplicationEventPool applicationEventPool)
     : base(applicationEventDispatcher)
 {
     InitializeComponent();
 }
Now we have a reference to the `ApplicationEventPool` in the `MainForm` lets modify the code in the `HelloWorldButton_Click` button handler method.
private void HelloWorldButton_Click(object sender, EventArgs e)
 {
     HelloWorldShouted @event;

     var eventAlreadyCached = _applicationEventPool.TryGet(out @event);
     if (!eventAlreadyCached)
     {
         @event = new HelloWorldShouted();
         _applicationEventPool.TryAdd(@event);
     }

     ApplicationEventDispatcher.Dispatch(@event);
 }
So now we declare an event but we wont instantiate it yet. We will try and get this event from the `ApplicationEventPool` and if it exists we will pass that to teh event dispatcher, but if one does not exist then we will create one and pass that instead.

Clean-Up

We do have an small clean-up task to do in the `MainProcess` where the `ApplicationEventPool` was instantiated. We must clear the pool in the `Dispose(bool)` method.
protected override void Dispose(bool disposing)
 {
     if (Disposed) return;

     if (disposing)
     {
         // Free other managed objects that implement IDisposable only
         _mainFormController.Dispose();
         _applicationEventPool.Clear();
         UnwireApplicationEventHandlers();
     }

     // release any unmanaged objects
     // set the object references to null

     Disposed = true;
 }

Summary

So now we can reuse any common events through the lifetime of the application. However we are not out of the woods yet. Why? Well, this event pool is great for simple events, that carry no data or immutable data that will be the same for each time the event is dispatched but what if our events are mutable or immutable after construction? We can't trust that they will be in the right state when we dispatch them so two class could dispatch the event and require different data within the event. so how will we handle that? Well we will look at handling them in the next part, part 4.

Disclaimer - Memory Usage

I am not an expert on Garbage Collection, so please be aware that pooling may not be the best solution for a memory problem using this Event Dispatcher. Pooling may lead to objects that should be short lived and would normally live in Generation 0 and get reclaimed quickly, being moved to Generation 1 or 2 and maybe not being reclaimed until the process ends. You can use `PerfMon.exe` or other profiling tools to help identify memory issues, and make an informed decision on how to combat them.

For further information on the Garbage Collector and [Garbage Collector Generations](https://msdn.microsoft.com/en-us/library/ee787088(v=vs.110).aspx#generations) please see [Fundamentals of Garbage Collection](https://msdn.microsoft.com/en-us/library/ee787088(v=vs.110).aspx)

Part One
Part Two
Thursday, February 11, 2016 10:13:32 PM (GMT Standard Time, UTC+00:00)  #    Comments [0] -
.Net | C# | CodeProject | Event Handling | Events | Windows Forms

Centralised Event Dispatcher in C# - Part 2

This is the second part in a series of posts where I am going to share with you the solution I have used in a recent project for a centralised event dispatcher. All of the source code will be available in my public GitHub repositories. The concept I have tried to realise is a central class that can raise events for any listener to subscribe to. In part one we created the event dispatcher class library, and in this part we are going to consume it from a windows forms application.

Assumptions

It is assumed that the reader of this article already has a good understanding of coding with C#, can create projects and solutions, classes and Windows Forms, and can add references to a project and import references into a class. It is also assumed the reader understands basic inheritance and interface implementation.

Dibware.EventDispatcher.UI

So now that is the actual event dispatcher complete so lets move to the windows forms project and write some code to use the event dispatcher. First we need to add a reference to the `Dibware.EventDispatcher.Core` project in the `Dibware.EventDispatcher.UI` project.

In the `Program.cs` we need a variable to hold a reference to an instance of the ApplicationEventDispatcher class which we will instantiate inside the `try` block of a `try-catch-finally` construct, ensuring the dispatcher is disposed in the `finally` block.
/// <summary>
/// The main entry point for the application.
/// </summary>
[STAThread]
static void Main()
{
     Application.EnableVisualStyles();
     Application.SetCompatibleTextRenderingDefault(false);

     ApplicationEventDispatcher applicationEventDispatcher = null;

     try
     {
         applicationEventDispatcher = new ApplicationEventDispatcher();

     }
     catch (Exception ex)
     {
         MessageBox.Show(ex.Message, @"Error!");
     }
     finally
     {
         if (applicationEventDispatcher != null) applicationEventDispatcher.Dispose();
     }
 }
Now assuming that we may have more than one class that will want to subscribe to the application events lets now create a base class that all subscribing classes will inherit from. I'm going to name it `ApplicationEventHandlingBase` and place it in a folder called `base`. This base class will implement `IDisposable` as we are going to want to clear up any event handlers when we finish with the objects that implement this class.
internal abstract class ApplicationEventHandlingBase : IDisposable
{
     protected bool Disposed { get; set; }

     protected abstract void Dispose(bool disposing);

     public void Dispose()
     {
         Dispose(true);
         GC.SuppressFinalize(this);
     }
 }
We are going to need a private field to hold a reference to an instance of the `ApplicationEventDispatcher` and we will want to initialise this from the constructor. We can then encapsulate the field with a protected property so all inherited classes have access to it. Finally we are going to define some methods for wiring and un-wiring events which must be implemented. That gives us this...
internal abstract class ApplicationEventHandlingBase : IDisposable
{
     private readonly IApplicationEventDispatcher _applicationEventDispatcher;

     protected ApplicationEventHandlingBase(IApplicationEventDispatcher applicationEventDispatcher)
     {
         if(applicationEventDispatcher == null) throw new ArgumentNullException("applicationEventDispatcher");

         _applicationEventDispatcher = applicationEventDispatcher;
     }

     protected IApplicationEventDispatcher ApplicationEventDispatcher
     {
         get { return _applicationEventDispatcher; }
     }

     protected bool Disposed { get; set; }

     protected abstract void Dispose(bool disposing);

     public void Dispose()
     {
         Dispose(true);
         GC.SuppressFinalize(this);
     }

     protected abstract void UnwireApplicationEventHandlers();
     protected abstract void WireUpApplicationEventHandlers();
 }
Now we have some base implementation for classes that will handle the application events, lets create the main process class, which will inherit from the base event handling class. Implementing the inherited and abstract members along with the Dispose pattern gives us this.
public MainProcess(IApplicationEventDispatcher applicationEventDispatcher)
     : base(applicationEventDispatcher)
 {
 }

 ~MainProcess()
 {
     Dispose(false);
 }

 protected override void Dispose(bool disposing)
 {
     if (Disposed) return;

     if (disposing)
     {
         // Free other managed objects that implement IDisposable only

     }

     // release any unmanaged objects
     // set the object references to null

     Disposed = true;
 }

 protected override void UnwireApplicationEventHandlers()
 {
 }

 protected override void WireUpApplicationEventHandlers()
 {
 }
We can now construct this in the `Main` method of `program.cs` using the reference to the `ApplicationEventDispatcher` and make the call to run the application, not forgetting to add clean up for it in the `finally block`.
/// <summary>
/// The main entry point for the application.
/// </summary>
[STAThread]
static void Main()
{
     Application.EnableVisualStyles();
     Application.SetCompatibleTextRenderingDefault(false);

     ApplicationEventDispatcher applicationEventDispatcher = null;
     MainProcess mainProcess = null;
     try
     {
         applicationEventDispatcher = new ApplicationEventDispatcher();
         mainProcess = new MainProcess(applicationEventDispatcher);

         Application.Run();
     }
     catch (Exception ex)
     {
         MessageBox.Show(ex.Message, @"Error!");
     }
     finally
     {
         if (mainProcess != null) mainProcess.Dispose();
         if (applicationEventDispatcher != null) applicationEventDispatcher.Dispose();
     }
 }
So lets crack on and create controller class that will be responsible for opening the main form for the application. I'm going to name this `MainFormController` and as it will be responding to events it will inherit from the `ApplicationEventHandlingBase` class and we will implement the dispose pattern again, although we will leave it without any actual clean-up implementation for the moment. I'll add this class to a folder names `FormControllers`
internal class MainFormController : ApplicationEventHandlingBase
{
     public MainFormController(IApplicationEventDispatcher applicationEventDispatcher)
         : base(applicationEventDispatcher)
     {
     }

     ~MainFormController()
     {
         Dispose(false);
     }

     protected override void Dispose(bool disposing)
     {
         if (Disposed) return;

         if (disposing)
         {
             // free other managed objects that implement IDisposable only

         }

         // release any unmanaged objects
         // set the object references to null

         Disposed = true;
     }

     protected override void UnwireApplicationEventHandlers()
     {
         throw new System.NotImplementedException();
     }

     protected override void WireUpApplicationEventHandlers()
     {
         throw new System.NotImplementedException();
     }
 }
As this responsibility of this class will be to handle all actions and behaviour for the main form then we had better add  a for for it to work with, so let's create a form called `MainForm` and add it to a "Forms" folder. we are not to fussed about what it looks like for the moment, we just want something that the `MainFormController` can display when it needs to. Switching back to the `MainFormController` we need to add a private field to hold a reference to the form and lets instantiate it from the constructor. _Please note this article is not about good windows form application design so do not take my way of displaying forms as any kind of windows forms application gospel, its purely to show how you can hook into the EventDispatcher!_

So when do we want this form to display? Well ideally as soon as the main process has started, so lets switch back to the `MainProcess` class and create a new public method called `Start`, which we will call immediately after instantiating the `MainProcess` in the `Main` method of `program.cs`
applicationEventDispatcher = new ApplicationEventDispatcher();
mainProcess = new MainProcess(applicationEventDispatcher);
mainProcess.Start();
The `Start` method will do nothing except raise a new `ProcessStarted` event, using our event dispatcher.
public void Start()
{
    ApplicationEventDispatcher.Dispatch(new ProcessStarted());
}
Now as we haven't actually created a `ProcessStarted` we had better get on and do it, so lets create one in a new folder called `Events`. The `ProcessStarted` event class will implement the `IApplicationEvent` contract, which which the 'ApplicationEventDispatcher' states must be so. There is much else going on in this event, it does not have any data to go with it, but in time you may decide you want to add some, like maybe a `TimeStamp` which some class that will handle this event may wish to use. For the moment and for simplicity, lets just leave this class empty.
internal class ProcessStarted : IApplicationEvent
{
}
So thats all very well but nothing is listening for this event yet, but we do have a class that wants to, the `MainFormController`. So lets create a private field for that controller in the `MainProcess` class and instantiate it in the constructor of `MainProcess` handing it a reference to the `ApplicationEventDispatcher`
private MainFormController _mainFormController;

public MainProcess(IApplicationEventDispatcher applicationEventDispatcher)
     : base(applicationEventDispatcher)
{
     _mainFormController = new MainFormController(applicationEventDispatcher);
}
We can now switch back to the `MainFormController`and wire up the handler for the `ProcessStarted` event  handler in the `WireUpApplicationEventHandlers` method...
protected override sealed void WireUpApplicationEventHandlers()
{
     ApplicationEventDispatcher.AddListener<ProcessStarted>(HandleProcessStarted);
}
... and then create a method called `HandleProcessStarted` which will respond to the `ProcessStarted` event, which in this case will simply show the `_mainForm`.
private void HandleProcessStarted(ProcessStarted @event)
{
    _mainForm.Show();
}
We will need to ensure `WireUpApplicationEventHandlers` is called from the constructor of the `MainFormController`, and may need to ensure that method as sealed to prevent a virtual member call compile error. if we run up the application then we should see the `MainForm` is displayed once the process is started. Our event dispatcher is working. What we have not done yet is any clear up of any resources, so lets take a look at that.

One the `MainForm` lets create a button which we will use to exit the application and add a `Click` handler for it in the code behind the form. We want this form to also be able to raise application events so it will need to be able to have a reference to the `ApplicationEventDispatcher`. So I am going to go against 'YAGNI' and create and create a base form class which will handle some of this for us. Within the `Forms` folder I am going to create a new folder named `Base`, and within that create a class named `ApplicationEventHandlingFormBase` which will inherit from `System.Windows.Forms.Form`. It will hold a private reference to the `ApplicationEventDispatcher` which will be passed in the constructor. You may notice we need a default parameterless constructor for the visual studio form designer. I have marked this with the `ObsoleteAttribute` to prevent the developer trying to call it! I have also added a protected property to allow all inherited classes access to the `ApplicationEventDispatcher` and two virtual methods for wiring and un-wiring application event handlers.
public class ApplicationEventHandlingFormBase : Form
 {
     private readonly IApplicationEventDispatcher _applicationEventDispatcher;

     [Obsolete("Required by form designer", true)]
     protected ApplicationEventHandlingFormBase()
     {
     }

     protected ApplicationEventHandlingFormBase(IApplicationEventDispatcher applicationEventDispatcher)
     {
         if (applicationEventDispatcher == null) throw new ArgumentNullException("applicationEventDispatcher");

         _applicationEventDispatcher = applicationEventDispatcher;
     }

     protected IApplicationEventDispatcher ApplicationEventDispatcher
     {
         get { return _applicationEventDispatcher; }
     }

     protected virtual void UnwireApplicationEventHandlers()
     {
     }

     protected virtual void WireUpApplicationEventHandlers()
     {
     }
 }
We now need to make our `MainForm` inherit from `ApplicationEventHandlingFormBase` instead of `System.Windows.Forms.Form` and add a `IApplicationEventDispatcher` argument to the constructor...

public partial class MainForm : ApplicationEventHandlingFormBase
{
    public MainForm(IApplicationEventDispatcher applicationEventDispatcher)
        : base(applicationEventDispatcher)
    {
        InitializeComponent();
    }
...and pass a reference to the `ApplicationEventDispatcher` to it when it is constructed in the `MainFormController`
_mainForm = new MainForm(applicationEventDispatcher);
We can now raise a new event `ProcessExiting` in the `ExitButton_Click` handler of the `MainForm`.
private void ExitButton_Click(object sender, EventArgs e)
{
     Hide();
     ApplicationEventDispatcher.Dispatch(new ProcessExiting());
}
We have not yet created a class for that event, so lets do that back in the `Events` folder, ensuring it implements `IApplicationEvent`.
internal class ProcessExiting : IApplicationEvent
{
}
So now we need to decide what class which we already have may be interested in subscribing to that event. In my mind this is the `MainProcess` class, so in the `WireUpApplicationEventHandlers` we are going to hook up a listener to this event.
protected override void WireUpApplicationEventHandlers()
{
     ApplicationEventDispatcher.AddListener<ProcessExiting>(HandleProcessExiting);
}
and create the handler method which exists the application.
private void HandleProcessExiting(ProcessExiting @event)
{
    Application.Exit();
}
...and ensure that the `WireUpApplicationEventHandlers` is called from the `Start` method.
public void Start()
{
    WireUpApplicationEventHandlers();
    ApplicationEventDispatcher.Dispatch(new ProcessStarted());
}
We should probably dispose of `_mainForm` and set it to null in the `Dispose(bool)` method of the `MainFormController` too.
    
So lets run up the application and watch as the `MainForm` is displayed. Clicking the exit button closes the form and the application exits. So all is bright and rosy in this exciting event driven world, hey? Well not quite. If you place a break point in the `RemoveAllListeners` method of `ApplicationEventDispatcher` you will see this is called and the both of the event handlers are removed here. The issue we have is it's not really the responsibility for the `ApplicationEventDispatcher` to clear up after all of the classes which subscribe to its events. Its should still do a final check and clear up, but ideally each subscriber should clear up after its self.

Clean up

So lets look at the two classes which have subscribed to events from the `ApplicationEventDispatcher`. We have `MainProcess` and `MainFormController`. Now both of these classes implement `IDisposable`, so in the `disposing` code path of the `Dispose(bool)` method of both of these classes lets call `UnwireApplicationEventHandlers()`. Also in the `Dispose(bool)` method of  the `MainProcess` lets also ensure `Dispose` is called on the `_mainFormController`, so it can call through and un-wire it's handlers.
protected override void Dispose(bool disposing)
 {
     if (Disposed) return;

     if (disposing)
     {
         // Free other managed objects that implement IDisposable only
         _mainFormController.Dispose();
         UnwireApplicationEventHandlers();
     }

     // release any unmanaged objects
     // set the object references to null

     Disposed = true;
 }
Now if we move to the `UnwireApplicationEventHandlers` method of each class we will call
ApplicationEventDispatcher.RemoveListener<ProcessStarted>(HandleProcessStarted);
 ... for the 'MainFormController' class and...         
ApplicationEventDispatcher.RemoveListener<ProcessExiting>(HandleProcessExiting);
... for the `MainProcess` class respectively.

Now if we run the application with a breakpoint in the `RemoveAllListeners` method of `ApplicationEventDispatcher` you will see there are no handlers registered. Bingo! All subscribers that we currently have are cleaning up after themselves. What good little children we have! And we can feel warm and fluffy as we know we are doing our bit to help the GarbageCollector.
    
In part three we will look at pooling events commonly used events, as spawning lots of new event objects could lead to problems in a memory concious system.

Full source code available here at My EventDispatcher GitHub repository

Part One

Thursday, February 11, 2016 7:13:51 AM (GMT Standard Time, UTC+00:00)  #    Comments [0] -
.Net | C# | CodeProject | Event Dispatcher | Event Handling | Events | Windows Forms
Categories
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Archive
<May 2016>
SunMonTueWedThuFriSat
24252627282930
1234567
891011121314
15161718192021
22232425262728
2930311234
Blogroll
 DAVID HEINEMEIER HANSSON
Creator of ruby on Rails
 Harry Pierson
Passion * Technology * Ruthless Competence
 Joshua Flanagan
A .NET Software Developer
 Martin Ffowler
Author, speaker, and loud-mouth on the design of enterprise software
 Michael Schwarz's Blog
Developing applications on the Microsoft platform since Windows 3.1!
 Scot GU
Scott Guthrie lives in Seattle and builds a few products for Microsoft
 Scott Hanselman
Programming Life and the Zen of Computers
About the author/Disclaimer

Disclaimer
The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.

© Copyright 2016
Duane Wingett
Sign In
Statistics
Total Posts: 83
This Year: 5
This Month: 0
This Week: 0
Comments: 61
Themes
Pick a theme:
All Content © 2016, Duane Wingett
DasBlog theme 'Business' created by Christoph De Baene (delarou)