Thanks for both of these bug reports (and sorry for the delay in responding). I've taken a look and I'm definitely seeing the same behavior as you are on 1.1. On current 2.0 builds things are a little different - but there's been some churn there since Alpha 5, specifically around conversions which likely fixed the problem. I saw another issue where we couldn't create a delegate to a bound-builtin function and fixed that on my machine. Now I see:
I am the built-in handler i got an event, i am happy. another one an event too, is happy too. yet another eventhandler, this must be enough. Removed event handler: ResetableEventcontainer.ResetableEventcontainer+MyEventCallback Removed event handler: ResetableEventcontainer.ResetableEventcontainer+MyEventCallback Removed event handler: ResetableEventcontainer.ResetableEventcontainer+MyEventCallback Removed event handler: ResetableEventcontainer.ResetableEventcontainer+MyEventCallback removed 4 event handlers after removal, nothing should happen here: now we re-add a handler, it should work again: I am the built-in handler i got an event, i am happy. testing adding on csharp-side, instead: I am the built-in handler i got an event, i am happy. I am the built-in handler Is that the correct output? If so then it looks like this will be fixed in the release after Alpha 6 (which just went out today). If you want to patch a copy of alpha 6 on your own you can just make BoundBuiltinFunction.LanguageContext return DefaultContext.Default.LanguageContext instead of throwing NotImplementedException. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Toni Alatalo Sent: Monday, November 05, 2007 6:32 AM To: users@lists.ironpython.com Subject: [IronPython] bugs with event handlers in 1.1 and 2.0 alpha 5 Greetings, when making a scripting system with IronPython in an embedded context I encountered first a bug in 1.1 in re-adding event handlers that had been cleared in-between (I wanted that to be able to refresh the py written handlers on the fly) - that is reported as bug #13685 http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=13685 While making the test case for that I came across a different problem in 2.0 alpha 5: [#13687] Registering c#-written methods as event handlers from ironpy throws TypeError: Object is not callable. http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=13687 A minimalish test case for both is available at http://studio.kyperjokki.fi/engine/IronPythonEventReaddition Curiously enough, 2.0 alpha5 did not work for me in the actual application that am developing - the fact that this test case does gives good hope that I can get it working there it too (I thought the case is similar..). This whole GetInvocationList() seems to be a strange beast, it is only available in the same class where the event is defined - not to others even if whe event is public, nor even in subclasses (yes, not even in c#-written subclasses - that's why my first test case that featured a WinForm with buttons etc could not be completed (I could not subclass a Button that'd have such a method for clearing event callbacks). The idea in the app that am developing is that user written scripts can register event handlers freely, so when clearing them to add new versions of the functions there, I don't have references to the funcs that the old version of the script had added. Am now using a workaround where the whole instance that has the handlers is re-initialized upon such a restart, but would like to have the initial plan of just redefining event handlers on the fly work too. So hopefully that'll smooth on 2.0. ~Toni _______________________________________________ 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