WPF 4.5 – Part 2 : Improved WeakEventManager

memory leaks were, are and always will be a concern in an application. one of it’s classical origin is unsubscribed events handler.

the weak event pattern is here to the rescue but it is quite tedious to implement.

in this post we’ll see how the wpf teams ease up our life when using the weakeventmanager class.

this post is a part of a series about the new features of wpf 4.5 .

generic weak event manager

prior to wpf 4.5 you had too create a weak event manger for every event you want to subscribe too.

now it’s over and you can use a generic version of the weakeventmanager class.

it takes as a generic parameters the type of the event’s source and the type of the dealed event arguments.

// type parameters:
//   teventsource:
//     the type that raises the event.
//
//   teventargs:
//     the type that holds the event data.
public class weakeventmanager<teventsource, teventargs> :
             weakeventmanager where teventargs : eventargs

it also exposes two statics methods on it:

• addhandler to add an handler on a event of a given source. it takes the name of the event as a parameters;
• removehandler to remove an handler if you know when;
  

it is done using reflection so you can have a little performance overhead using this object.

no more interface for the subscriber

prior to wpf 4.5, every subscriber to a weak-event must implements the iweakeventlistener. this is a very simple interface with this declaration:

public bool receiveweakevent(type managertype, object sender, eventargs e)

even if it’s easy and fast to implement, it is quite tedious. hopefully, implementing it is no more needed and you simply have to pass on a delegate when subscribing ! .

an example

let’s said you have an application with a main window and sometimes you show up child ones. this children subscribe to the activated event of the main window to know when the application is showed up. by using traditional event subscription, you could create a memory leak if you do not register from it. in the other hand, if you subscribe to this event using a weakeventmanager, you will never heard of it!

here is an example of the code to use:

//create 10 mo to be more visible in the process explorer
public byte[] data = new byte[10 * 1024 * 1024];
 
public leakingwindow()
{
    initializecomponent();
    weakeventmanager<window, eventargs>
        .addhandler(app.current.mainwindow, "activated", mainwindow_activated);
 
    //traditional event subscription: memory leak !
    app.current.mainwindow.activated += mainwindow_activated;
}
 
void mainwindow_activated(object sender, eventargs e)
{
    //do something here
}

to test this feature, i created a little demo app which create leaking window and dump the memory usage every 200ms. you can find this application on my dropbox folder (do you want to register and give me more space ? use this link !! )

for more informations on this topic, read this msdn page .