Re: [IronPython] Overriding derived methods
Another message back from the other side of a black hole... sorry for the delay
on this.
You're hitting the other side of "in many cases"... Unfortunately if the other
method is called then we'll dispatch to the incorrect method there too... This
is fixed in beta 7 which should be out real soon now.
Do you want to help develop Dynamic languages on CLR?
(http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038)
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jonathan Jacobs
Sent: Friday, May 05, 2006 10:19 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Overriding derived methods
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
___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Overriding derived methods
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
Re: [IronPython] Overriding derived methods
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. Do you want to help develop Dynamic languages on CLR? (http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jonathan Jacobs Sent: Friday, May 05, 2006 8:50 AM To: Discussion of IronPython Subject: [IronPython] Overriding derived methods Hi, I'm wondering how I override methods in a derived object, I'm not sure whether this is the problem I'm experiencing or not but it looks that way. Defining my own form object, with OnKeyUp method: >>> class MyForm(Form): ... def OnKeyUp(self, e): ... print '!!!' ... Form.OnKeyUp(self, e) ... The problem is that OnKeyUp in my Python object doesn't actually fire when it should. I know I could do this by attaching an event but according to the MSDN docs overriding the method in derived classes is the preferred way to handle the event, it certainly seems cleaner. Regards -- Jonathan ___ 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
