C＃ - 试图找到剩余的事件处理程序防止控制外出的范围 [英] C# - Trying to find remaining EventHandler preventing control from going out of scope

问题描述

长话短说，我继承了一个相当复杂的应用程序，我试图追查涉及形式的内存泄漏。现在，每一个窗体关闭时间，提出了一个新的，旧的保留在内存中。我找到了一个问题与程序（显然，只要静态事件设置，没有该控件实例被认为超出范围内的控制拥有和设置静态事件，即使没有提及其他人说控制）。现在，我试图追查其余问题

Long story short, I inherited a fairly complex application and I'm trying to track down a memory leak involving a form. Right now, every time the form is closed and a new one brought up, the old one remains in memory. I tracked down an issue with a static event owned and set by a control within the program (apparently, so long as the static event was set, no instance of that control was considered out of scope, even when no one else referred to said controls). Now, I'm trying to track down the remaining issue.

使用MemProfiler和蚂蚁内存配置文件，我已经了解到，根执行路径是这样的：

Using MemProfiler and ANTS Memory Profile, I've learned that the root execution path goes like this:

FormOpenWatch        <--       The item which remains active
System.EventHandler -- (this as Delegate)._target
System.Object[]
System.EventHandler -- (this as MultiCastDelegate)._invocationList
System.ComponentModel.EventHandlerList+ListEntry  --  handler
System.ComponentModel.EventHandlerList+ListEntry  --  next
System.ComponentModel.EventHandlerList+ListEntry  --  next
System.ComponentModel.EventHandlerList+ListEntry  --  next
System.ComponentModel.EventHandlerList+ListEntry  --  next
System.ComponentModel.EventHandlerList  --  head
PTU.MdiPTU  --  (this as Component).events        <--       The base application

任何人有什么我可能会寻找任何见解？我发现一个事件所示添加了基本应用程序，并确保当窗体被处置，它被删除，但似乎没有已经解决了这一问题。

Anyone have any insight for what I might be looking for? I've found a Shown event added with the base application, and ensured that it gets removed when the form is being disposed of, but that doesn't seem to have fixed the problem.

许多感谢您的帮助，您可以提供

Much thanks for any help you can provide.

的后来编辑：的我还以为我已经成功地解决了这几次现在，我仍然有问题。这个问题似乎是从我的绘图仪类（以及各种派生类）所产生的具有这种公共静态事件MouseEventHandler MultiCursorMouseMove;事件。我们有一个光标，它显示在鼠标的位置的值和图形的时间。最初，该制作一个图形的时间，但提出的请求，以允许用户切换，其中移动鼠标移动横过所有显示图形的曲线图的模式。我写了一个初步治疗挂钩事件处理器中的项目被实例化，我整个池塘的合作伙伴改写它使用静态事件，该事件被分配到施工的每个项目。他的办法是更优雅和效果更好。所有不同之处在于它是导致内存泄漏。使用内存分析软件显示，每次我试图摆脱的形式持有的地块，我留下了许多直接事件处理程序的根处置情况的案件。在每个这些，它表明对象可以是一个绘图仪或对象由绘图仪指向。并且，在每个这些，基链路是一个MultiCursorMouseMove EVENTLIST指向这些对象。我认为这是什么情况是，绘图仪活着，因为它反过来链接到绘图仪这种静态的事件。我已成功地验证MultiCursorMouseMove是通过调试空在凭借我的处置代码为每个绘图仪取出事件，但运行在同一点剖析一个给定的点仍然显示这条产业链，从MultiCursorMouseMove这些类。

Later I have thought I've successfully solved this several times over now, and I'm still having issues. The problem seems to be stemming from my Plotter class (and various derived classes) having this "public static event MouseEventHandler MultiCursorMouseMove;" event. We have a "cursor" which displays the value and time of the graph at the mouse's location. Originally, this worked on one graph at a time, but a request was made to allow the user to toggle a mode where moving the mouse moved the plot across all of the displayed graphs. I wrote up an initial treatment hooking the EventHandlers in as the items were instantiated, and my partner across the pond rewrote it to use the static event, which gets assigned to each item on construction. His way is much more elegant and works better. All except that it's resulted in memory leaks. Using the memory profiling software has shown that every time I try to get rid of the form holding the plots, I'm left with a number of cases of "Disposed instance with direct EventHandler roots". In each of these, it shows that the object is either a Plotter, or an object pointed to by the Plotter. And, in each of these, the base link is that a MultiCursorMouseMove EventList points to these objects. I think that what's happening is that the Plotter is staying alive because it has this static event which in turn is linked to the Plotters. I have managed to verify that MultiCursorMouseMove is null through the debugger at a given point by virtue of my Dispose code removing the event for each Plotter, and yet running the profiler at that same point still shows this chain from MultiCursorMouseMove to these classes.

我出关于如何目前解决这个问题的想法。有人吗？

I'm out of ideas on how to fix this currently. Anyone?

推荐答案

如果MdiPTU是为您的应用MDI父窗体，这听起来像FormOpenWatch可能已经订阅了它的事件之一。如果还没有这样做的直接，你可能会发现在FormOpenWatch超认购，或甚至在其他的代码，可以线了从MdiPTU事件FormOpenWatch方法的执行。

If MdiPTU is the MDI parent form for your application, it sounds like FormOpenWatch might have subscribed to one of its events. If it hasn't done so directly, you might find the subscription in a FormOpenWatch superclass, or perhaps even in other code that can wire up execution of a FormOpenWatch method from an MdiPTU event.

这篇关于C＃ - 试图找到剩余的事件处理程序防止控制外出的范围的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！