WPF ICommandSource Implementations Leak Memory!
Actually the title of this article should be entitled “How to use WeakEventManager with ICommand implementations”, but the memory leak title is more exciting (and true)
Overview
Some WPF controls, such as Buttons, are command sources. A command source has 3 properties, Command, CommandParameter and CommandTarget. When the control does it’s action (like Click for Button)it Executes the command, using the CommandParameter and CommandTarget as inputs.
WPF has provided an interface called ICommandSource to encapsulate this concept. (Although there seems to be nothing significant which consumes the interface – just classes which implement it.)
Most (all?) command sources implementations care about the CanExecute state, and usually disable themselves if CanExecute is false. The implementations listen to the CanExecuteChanged event for the command, and when it is raised query the new CanExecute status.
And that is where the issue begins – the implementations don’t unsubscribe from the event (except when the Command property changes). So if the command object has a lifetime longer than any control(s) which list to it’s CanExecuteChanged event it will cause a memory leak of the control. This is because when you register a handler for an event the delegate isn’t just a function pointer, but also include a reference to your instance.
The RoutedCommand Winkle
At this point you are probably saying to yourself “The logic seems sound, but I use commands and my app doesn’t appear to leak”.
The answer is because most apps use RoutedCommand, rather than their own implementation of ICommand. The RoutedCommand.CanExecuteChanged implementation is to be a proxy for CommandManager.RequerySuggested, which if you read the docs or look at the IL keeps a weak reference to the delegate. That allows the delegate to be GCed, and along with it the strong reference to the command source which subscribed to the event.
So to hit this you need to have a custom ICommand implementation which implements the CanExecute event the way most .NET events are implementd.
Why I Think WPF’s CanExecuteChanged Implementation Is Wrong
No doubt someone on the WPF team thought they were being rather smart –after since most RoutedCommands are declared as static fields their lifetime is roughly the application’s lifetime. But I don’t think they were clever enough – because they redefined the standard contract for a .NET event.
Now anyone subscribing with RoutedCommand.CanExecuteChanged needs to be aware of this non-standard behavior – since if they don’t hold a strong reference to their delegate then it will be GCed and at some point the event seems to stop working. (A really fun problem to debug BTW)
Since they also have this nice ICommand interface which RoutedCommand is one implementation it also means that if you implement an ICommand you have to be aware of this behavior and also implement your event in a similar way holding weak references to the delegate, because the built-in consumers of the event (Button, etc…) rely on this behavior.
Furthermore since RoutedCommand.CanExecuteChanged event is really CommandManager.RequerySuggested each RoutedCommand instance shares the same event. This means when the event is raised the sender field is null. Another inconsistency from regular .NET event behavior.
To me this is a big mess, and unfortunately one we probably will have to live with for the whole lifetime of WPF. Why I consider it a mess is not the technical specifics of the solution, but because they redefined the standard .NET event contract.
While we could argue that the .NET event contract has flaws, the fact of the matter is it is now a standard. And this means that both producers and consumers of that contact know how to correctly implement their end.
What RoutedCommand.CanExecuteChanged has done is made a different contract where it holds weak references to the delegate. This means that producers and consumers need to be coded differently that a standard .NET event. That is the issue from my point of view.
If the WPF team has decided to do their own custom Observer pattern implementation that didn’t overload “event” I would be happy, since it would clearly be a different contract. By this I mean imagine if on ICommand instead of defining the CanExecuteChanged event they did something like this:
interface ICommand
{
void RegisterCanExecuteListener(EventHandler listener);
void UnregisterCanExecuteListener(EventHandler listener);
bool CanExecute(object parameter);
void Execute(object parameter);
}
Then they could clearly document the contract for the CanExecuteListener and no one would get confused with .NET event semantics.
How To Properly Implement A Command Source
Now that I’m done with my rant I’ll give you some advice on how to deal with this. Specifically in how to correctly implement your own command source implementation which will not leak regardless of the implementation of ICommand.
The short answer is to use WeakEventManager.
Unfortunately we need the long answer because since RoutedCommand.CanExecuteChanged doesn’t follow the standard contract it doesn’t work with WeakEventManager. Specifically because:
· WeakEventManager doesn’t hold a strong reference to the delegate, so it will be GCed
· Since the sender parameter is null, WeakEventManager can’t which listener to deliver the event to
Notice the impact of not following the standard pattern means you can't use components designed to work with the standard pattern.
The key is in the WeakEventManager implementation to use a proxy class for the ICommand implementation. This proxy class does 2 things:
· Holds a strong reference to the delegate registered with ICommand.CanExecuteChanged
· Since there is a 1:1 relationship between the proxy and the ICommand, and the handler delegate has a reference to the proxy we can get the reference to the associated ICommand
The complete implementation of a WeakEventManager which works with all ICommand implementations is in the attached file. The class is called CommandCanExecuteChangedWeakEventManager.
Then all the command source implementation needs to do is to use that and all will be well.
The Attached Project
If you build and run the attached project you will see a couple of buttons. One demonstrates the memory leak using Button. Simply open task manager, click the button and watch memory usage go up. Click the GC button to ensure yourself that the objects really have a strong reference back to them.
The other parts of the UI are to demonstrate that CommandCanExecuteChangedWeakEventManager really works, both to deliver events and to avoid the memory leak.
Use at your own risk and other standard disclaimers apply.
Enjoy
Comments
Anonymous
May 29, 2009
PingBack from http://microsoft-sharepoint.simplynetdev.com/wpf-icommandsource-implementations-leak-memory/Anonymous
June 17, 2010
Hi, thanks for the explanation and code. Regarding your CommandProxy, I was wondering why it uses itself and not the wrapped Command as the sender of the event. In code, why private void OnCanExecuteChanged(EventArgs eventArgs) { var eh = this.CanExecuteChanged; if (eh != null) { eh(this, eventArgs); } } and not private void OnCanExecuteChanged(EventArgs eventArgs) { var eh = this.CanExecuteChanged; if (eh != null) { eh(this.Command, eventArgs); } }Anonymous
June 17, 2010
I understood now: your OnCanExecuteChanged handler calls DeliverEvent with proxy.Command.