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
[email protected]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
