<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Preventing Event-based Memory Leaks – WeakEventManager</title>
	<atom:link href="http://reedcopsey.com/2009/08/06/preventing-event-based-memory-leaks-weakeventmanager/feed/" rel="self" type="application/rss+xml" />
	<link>http://reedcopsey.com/2009/08/06/preventing-event-based-memory-leaks-weakeventmanager/</link>
	<description>Thoughts on C#, WPF, .NET, and programming for Scientific Visualization</description>
	<lastBuildDate>Fri, 11 May 2012 16:07:35 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.2</generator>
	<item>
		<title>By: Reed</title>
		<link>http://reedcopsey.com/2009/08/06/preventing-event-based-memory-leaks-weakeventmanager/#comment-72</link>
		<dc:creator>Reed</dc:creator>
		<pubDate>Sat, 19 Sep 2009 15:07:57 +0000</pubDate>
		<guid isPermaLink="false">http://reedcopsey.com/?p=55#comment-72</guid>
		<description>It&#039;s always a good idea to call RemoveListener.  The cleanup pass will occur, and basically remove the listener automatically, if the sender has been finalized, and will prevent the sender from keeping the listener rooted, even if you forget.  

However, calling RemoveListener keeps the cleanup pass shorter (which is important), and also &quot;stops&quot; the listener from receiving events, which is also important if you&#039;re disposing the listener (or you will, if designed correctly, start getting ObjectDisposedExceptions).</description>
		<content:encoded><![CDATA[<p>It&#8217;s always a good idea to call RemoveListener.  The cleanup pass will occur, and basically remove the listener automatically, if the sender has been finalized, and will prevent the sender from keeping the listener rooted, even if you forget.  </p>
<p>However, calling RemoveListener keeps the cleanup pass shorter (which is important), and also &#8220;stops&#8221; the listener from receiving events, which is also important if you&#8217;re disposing the listener (or you will, if designed correctly, start getting ObjectDisposedExceptions).</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Sam Azish</title>
		<link>http://reedcopsey.com/2009/08/06/preventing-event-based-memory-leaks-weakeventmanager/#comment-71</link>
		<dc:creator>Sam Azish</dc:creator>
		<pubDate>Sat, 19 Sep 2009 10:23:04 +0000</pubDate>
		<guid isPermaLink="false">http://reedcopsey.com/?p=55#comment-71</guid>
		<description>Thanks for this very informative article. One question I have though is regarding this statement:

&quot;The cleanup pass is handled via a dispatcher schedule of a delegate setup to run when the dispatcher becomes idle.  This goes through and unsubscribes any senders for whom the receiver is no longer valid.&quot;

By this do you mean that it is not necessary to call RemoveListener before disposing the receiver? I thought we have to call RemoveListener to release any event handler on week event manager part on the sender (StopListening method).</description>
		<content:encoded><![CDATA[<p>Thanks for this very informative article. One question I have though is regarding this statement:</p>
<p>&#8220;The cleanup pass is handled via a dispatcher schedule of a delegate setup to run when the dispatcher becomes idle.  This goes through and unsubscribes any senders for whom the receiver is no longer valid.&#8221;</p>
<p>By this do you mean that it is not necessary to call RemoveListener before disposing the receiver? I thought we have to call RemoveListener to release any event handler on week event manager part on the sender (StopListening method).</p>
]]></content:encoded>
	</item>
</channel>
</rss>
 
