Dino Viehland wrote: > There's a bug in beta 5 and beta 6 where we can sometimes fail to call the > correct derived method. You can work around the bug in many cases w/: > > Class MyForm(Form): > def __init__(self): > self.OnKeyUp = self.OnKeyUp > def OnKeyUp(self, e): > ... > > Unfortunately you can still get some erattic behavior w/ the workaround in > place. > > This will be fixed for our beta 7 release. This happens only when deriving > from a type that has a large number of virtual methods, and unfortunately > System.Windows.Forms hits this pretty heavily.
Thanks for the quick response, Dino. I've run into another (rather bizarre) situation, you'll need a few preliminary steps first: 1.) Create a vanilla "Windows Application" project in Visual Studio (C# 2005 Express Edition, not sure if this matters) 2.) Compile it, add the compiled assembly to somewhere in your path. I used the following code to reproduce the error: >>> clr.AddReferenceToFile('WindowsApplication1.exe') >>> from WindowsApplication1 import Form1 >>> class MyForm(Form1): ... def __init__(self): ... self.OnKeyUp = self.OnKeyUp ... def OnKeyUp(self, e): ... print e ... >>> frm = MyForm() >>> Application.Run(frm) Which yields the following output: System.Windows.Forms.PaintEventArgs System.Windows.Forms.KeyEventArgs etc. I'm really wondering about the PaintEventArgs object that sneaks in there. I haven't tried reproducing *all* of the generated C# code in pure IronPython code yet but the minimal form I mentioned in my previous email is not subject to this odd behaviour. Regards -- Jonathan _______________________________________________ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com