The fix for this is now checked in and has been pushed to CodePlex. Thanks for reporting!
From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of David DiCato Sent: Friday, February 19, 2010 12:31 PM To: Discussion of IronPython Subject: Re: [IronPython] Using a C# class in IronPython Hi Justin, this is definitely a valid bug; thanks for reporting it. We’re supposed to ignore any methods named GetMember/SetMember/DeleteMember unless they define the [SpecialName] attribute, but we fail to account for cases where there could be overloads. This is because the default binder calls type.GetMethod("SetMember") which throws when there are multiple matches. We should instead get all methods named SetMember and filter out the non-special ones. I already have a preliminary fix for this, and it should make it onto CodePlex within a few days. From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Justin Hartman Sent: Friday, February 19, 2010 11:09 AM To: Discussion of IronPython Subject: Re: [IronPython] Using a C# class in IronPython Thanks, Mark. That's all really good stuff, and essentially we are already doing the same things in our app. Where the problem comes in for me (I've narrowed it down a little bit) is that the IronPython binding code looks for a method called "SetMember" when I attempt to set an attribute. My class happens to have multiple overridden SetMember methods (which have nothing to do with Python, but make sense in my application domain), which causes Type.GetMethod() to throw an exception. I logged an issue in CodePlex (Item #26277: CLR class with overridden SetMember method causes "Ambiguous match found"<http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=26277>); you can take a look if you want to see the whole issue and how to repro. On Wed, Feb 17, 2010 at 9:58 AM, Mark Grice <markjoe...@gmail.com<mailto:markjoe...@gmail.com>> wrote: I'm not sure if this helps, but I use a C# class in my IronPython, and it works fine. Class is defined using the shorthand get; set; ie: public class ScreenTags { public String appWindowName { get; set; } public String fieldName { get; set; } public bool isDataField { get; set; } public bool isManual { get; set; } public String screenLabel { get; set; } public String description { get; set; } } (In actuality, it is a lot more than this, consisting of other classes, methods, etc...) Now, it may be bad practice, but I then simply use an object reference in Python, and assume it was instantiated. In other words, as far as Python is concerned, there is an instantiated object of ScreenTags called "screen". Python simply calls this whenever it wants to do something: ie. screen. appWindowName = "ThisName" I create the screen object in my C# code, and then add it as a reference to the python scope before I call the IronPython engine. So, on the C# side I: scptEngine = Python.CreateEngine(); scptRuntime = scptEngine.Runtime; scptScope = scptEngine.CreateScope(); AddAssemblies(scptRuntime); // call if you need to add other libraries, such as my class And before I actually call the Engine, I set the class in the Python scope -- still in C#: ScreenTags SOA_screen = new ScreenTags(); scptScope.SetVariable("screen", SOA_screen); scptSource = scptEngine.CreateScriptSourceFromFile(scriptFile); // scriptFile is Python code scptSource.Execute(scptScope); This is working fine. The class is actually really a loaded class, and it has all kind of goodies in it (ie pop up Windows forms, calls out to unmanaged code... all sorts of stuff). I never have a problem with any of it. I don't know if this helps (or even if it is good practice!) but it is working here. _______________________________________________ Users mailing list Users@lists.ironpython.com<mailto: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
