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 serie 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:
// The type that raises the event.
// 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:
[csharp]public bool ReceiveWeakEvent(Type managerType, object sender, EventArgs e)[/csharp]
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 !.
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];
.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.
20/10/2011 9 h 34 min
> it is quite fastidious to implement
> Even if it’s easy and fast to implement, it is quite fastidious.
Only a person can be fastidious. You want a different word or expression here, depending on your intended meaning.
1. excessively particular, critical, or demanding; hard to please: a fastidious eater.
2. requiring or characterized by excessive care or delicacy; painstaking.a
21/10/2011 15 h 56 min
You are right, I was thinking at \”tedious\”. Thank you.
26/01/2012 2 h 14 min
Couldn’t you replace that event name string with a safe lambda expression?
Anyway I’m sure you been thru linq expressions selectors and all that, probably beacuse of that error that an event can only appear before += or -= operators.
I do think there should be a language-level operator for weak referencing and weak event subscription. http://visualstudio.uservoice.com/forums/121579-v…
04/07/2012 1 h 32 min
There is another way, explained here: http://social.msdn.microsoft.com/Forums/en/wpf/th…
It's type-safe and fast. My guess is they didn't use this method because it's less dummy proof.