Dino Viehland wrote:
We don't always remember what we've wired up though. If you give us a delegate
which matches the type exactly we'll just go ahead and hook it up (to avoid
adding an extra level of indirection). Only if you give us some random
callable object will we remember it. It'd be easy enough for us to remember
but I wonder if this is really a good idea.
That sounds fair enough.
What if someone else has subscribed to the event? If you have the ability to clear the
events then you could cause someone elses subscription to go away. Maybe you
"know" that no one else will have subscribed but it does seem like this breaks
the encapsulation of events.
Well, in our case it is when we want to dispose of UI elements - so
anything listening *must* unsubscribe.
I do think we have the event leaks fixed (we hold no strong references at all now).
To trackl down leaks here I'd suggest using windbg & SOS to track down the
remaining references. You can !DumpHeap to list the entire heap, find the object
type you think is keeping everything alive, and then do !GCRoot on its address and
see who's keeping it alive.
This is what we do - and great fun it is too. :-)
Michael
Alternately you could use the weak event pattern.
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:users-
[EMAIL PROTECTED] On Behalf Of Michael Foord
Sent: Tuesday, December 02, 2008 11:49 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Event unhooking and IPy2
Marty Nelson wrote:
We've had probably with memory leaks on Windows Form subscribed menu
item clicks, just with plain vanilla C#.
Ok - it may well not be the fault of IronPython. (Certainly some event
handlers don't cause us problems whilst others do). On the other hand,
as IronPython *is* keeping track of all the handlers we add, an easy
interface to unhook them all would be extremely useful.
Michael Foord
Check out this link http://www.bobpowell.net/eventsubscribers.htm
(There
are some additional steps for System.Windows.Forms.Component), and
here's some sample code I wrote in C# that you could leverage:
[TestClass]
public class UnhookEventsTests
{
private class Item
{
public event EventHandler Clicked;
public void FireEvent()
{
if(Clicked != null)
{
Clicked(this, EventArgs.Empty);
}
}
}
[TestMethod]
public void UnhookEvents()
{
Item item = new Item();
item.Clicked += Clicked;
item.Clicked += Clicked2;
item.FireEvent();
Assert.AreEqual(2, callCount_);
FieldInfo field = typeof (Item).GetField("Clicked",
BindingFlags.NonPublic | BindingFlags.Instance);
Delegate del = (Delegate) field.GetValue(item);
Delegate[] list = del.GetInvocationList();
Assert.AreEqual(2, list.Length);
//This works:
//foreach (Delegate d in list)
//{
// item.Clicked -= (EventHandler) d;
//}
//This is more generic and avoids the cast to the
specific
handler type
EventInfo eventInfo = typeof (Item).GetEvent("Clicked");
foreach (Delegate d in list)
{
eventInfo.RemoveEventHandler(item, d);
}
item.FireEvent();
Assert.AreEqual(2, callCount_);
}
private int callCount_;
private void Clicked(object sender, EventArgs e)
{
callCount_++;
}
private void Clicked2(object sender, EventArgs e)
{
callCount_++;
}
}
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Kamil
Dworakowski
Sent: Saturday, November 29, 2008 1:16 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Event unhooking and IPy2
On Fri, Nov 28, 2008 at 11:39 AM, Michael Foord
<[EMAIL PROTECTED]> wrote:
Just as a follow up to this - the reason for the hack below is that
subscribing to events from IronPython is still causing our UI
objects
(and
their whole object graphs) to not be garbage collected.
To be fair, we have no reason to belive it is IronPython's fault. The
bug that event handlers would prevent garbage collection was fixed,
and we were able to remove *some* of the event nuking.
_______________________________________________
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
=======
Notice: This e-mail message, together with any attachments, contains
information of Symyx Technologies, Inc. or any of its affiliates or
subsidiaries that may be confidential, proprietary, copyrighted,
privileged and/or protected work product, and is meant solely for
the intended recipient. If you are not the intended recipient, and
have received this message in error, please contact the sender
immediately, permanently delete the original and any copies of this
email and any attachments thereto.
_______________________________________________
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog
_______________________________________________
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
_______________________________________________
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog
_______________________________________________
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
