Controls are like diapers: you don't want a leaky one [Implementing the WeakEvent pattern on Silverlight with the WeakEventListener class]

re: Controls are like diapers: you don't want a leaky one [Implementing the WeakEvent pattern on Silverlight with the WeakEventListener class]

kmkuntz — Tue, 20 Sep 2011 18:05:20 GMT

Yes sir that's what I'm doing - trying to figure out how to use their patched DragDropTarget. Looks like I'll have to grab the entire toolkit source unless there's something I'm missing (which is entirely likely).

I appreciate all the help David. This would have been quite a bit more difficult without the back and forth.

Kevin

re: Controls are like diapers: you don't want a leaky one [Implementing the WeakEvent pattern on Silverlight with the WeakEventListener class]

David Anson — Tue, 20 Sep 2011 17:32:22 GMT

Kevin,

Sorry about the trouble! However, from the comments of the issue you link to, it looks like folks may have been able to fix the leak. If you have time to experiment, maybe that would resolve the leak without requiring you to abandon the panel?

re: Controls are like diapers: you don't want a leaky one [Implementing the WeakEvent pattern on Silverlight with the WeakEventListener class]

kmkuntz — Tue, 20 Sep 2011 16:01:55 GMT

Using WinDbg I was able to locate the source of my memory leak (good!). Turns out it is caused by the use of a PanelDragDropTarget (bad!), as discussed here: silverlight.codeplex.com/.../7356.

Not sure how to resolve this one other than removing the panel, which will also remove functionality that our users are used to having.

Thanks for the advice.

re: Controls are like diapers: you don't want a leaky one [Implementing the WeakEvent pattern on Silverlight with the WeakEventListener class]

kmkuntz — Tue, 20 Sep 2011 13:48:23 GMT

Thanks for your help David. That clears up a lot.

re: Controls are like diapers: you don't want a leaky one [Implementing the WeakEvent pattern on Silverlight with the WeakEventListener class]

David Anson — Tue, 20 Sep 2011 05:13:23 GMT

Kevin,

Your understanding is correct: if the thing subscribing to the event has the same lifetime as the thing that exposes the event, there shouldn't be a leak concern because both instances will become garbage at the same time and the fact that one references the other won't matter. The big concern is when there's a long-lived (i.e., for the life of the application) collection with one of these "backward references" to an individual page instance - especially if that new instances of that page are created regularly! :)

re: Controls are like diapers: you don't want a leaky one [Implementing the WeakEvent pattern on Silverlight with the WeakEventListener class]

kmkuntz — Mon, 19 Sep 2011 14:30:27 GMT

Thanks for the response. I'll set the source to null upon leaving the view for sanity's sake, and will be checking out windbg immediately.

one last one - what about a simple, completely self-contained button click handler defined on my view for a button on my view? does that need to be unregistered? If the button is defined on the view it would seem that it should have the same lifetime as the view, and therefore shouldn't be a problem. it will die when the view goes, regardless of the handler.

is this correct? or should ALL handlers be unregistered?

Thanks for your time.

Kevin

re: Controls are like diapers: you don't want a leaky one [Implementing the WeakEvent pattern on Silverlight with the WeakEventListener class]

David Anson — Fri, 16 Sep 2011 21:06:54 GMT

Kevin,

Yes, it seems like the reference to App.StaticObservableCollectionA will remain present even when the view isn't current. HOWEVER, the platform's ItemsControl class (upon which ComboBox is built) already does the right thing here to maintain weak references, so this shouldn't be the source of a leak for you (assuming this isn't a platform bug). That said, if you want to help be *sure* and cover all the bases, you should be able to set the ItemsSource to null in an Unloaded handler for your view (the counterpart to the Loaded handler you're already using). Alternatively, maybe do the attach/detach as part of the OnNavigatedTo/From process.

You also might find it helpful to try to determine the source of the possible leak using the process I describe here: blogs.msdn.com/.../where-s-your-leak-at-using-windbg-sos-and-gcroot-to-diagnose-a-net-memory-leak.aspx

Hope this helps!

re: Controls are like diapers: you don't want a leaky one [Implementing the WeakEvent pattern on Silverlight with the WeakEventListener class]

Kevin — Fri, 16 Sep 2011 19:53:53 GMT

Hi Delay - I have a question regarding implementation of the above.

I have a SL navigation view with the following code (in the Loaded handler):

ComboBoxA.ItemsSource = null;

ComboBoxA.ItemsSource = App.StaticObservableCollectionA;

App.StaticObservableCollectionA is an ObservableCollection<Entity> - stored in App.xaml as a public static property, like so:

public static ObservableCollection<Business_Role> StaticObservableCollectionA { get; set; }

question one - this looks like a scenario that will cause my view to stay in memory even though i've navigated away from it. right?

question two - if the answer to question one is yes, how do I use this pattern to alleviate this problem? for better or worse, i have this all over my app...

the memory creeps and creeps as i move to and from views in this app. I'd like to put a lid on it. Thanks for your help.

Kevin

re: Controls are like diapers: you don't want a leaky one [Implementing the WeakEvent pattern on Silverlight with the WeakEventListener class]

David Anson — Fri, 11 Mar 2011 17:37:01 GMT

Jamil,

The code I post is under the Microsoft Public License (Ms-PL). There's a link to the full license from the "Information" section in the sidebar at the top of every post. The high-level summary is that you can use the code for pretty much anything you want. :)

re: Controls are like diapers: you don't want a leaky one [Implementing the WeakEvent pattern on Silverlight with the WeakEventListener class]

Jamil — Fri, 11 Mar 2011 11:25:36 GMT

Guys what the license for using WeakEventListener class in my code ?