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