Have you tried "import System" followed by
System.Activator.CreateInstance(System.Type.GetTypeFromProgID("QBXMLRP2.RequestProcessor")?
This should more closely resemble the behavior of the pywin32 code of
win32com.client.Dispatch("QBXMLRP2.RequestProcessor"). See
http://blogs.msdn.com/shrib/archive/2008/07/30/idispatch-support-on-in-ironpython-beta-4.aspx
for some info.
Thanks,
Shri
From: [email protected]
[mailto:[email protected]] On Behalf Of Dino Viehland
Sent: Friday, May 15, 2009 4:35 PM
To: Discussion of IronPython
Subject: Re: [IronPython] can anyone help me with COM access in ironpython?
[note my knowledge of this area is fuzzy at best but this is my understanding.
Maybe someone from the team can explain this better or give more accurate
information if I get anything wrong].
The reason why these are so different is to date IronPython has basically
gotten it's COM interop support "for free" from one of two locations:
1) The CLR providing interop assemblies to talk to COM objects (in 1.x)
2) DLR IDispatch support in IronPython 2.0
In 2.0 there's a command line option which gives you a hybrid of these options:
-X:PreferComInteropAssembly.
Ok, so that gives us two different modes... In 1.x, or when you use this
option, you generally get the normal .NET COM interop - so if you want
documentation on it you can go and look at normal .NET COM interop docs.
In mode 2 we're using the DLR which is directly talking to COM objects which
implement IDispatch. This is like class VB or VBA COM interop. It's a little
bit more limited in what it can do because the objects need to implement
IDispatch. So again if you wanted documentation you'd generally look at how to
use these objects from classic VB/VBA and just follow those instructions.
Obviously we weren't very confident about the DLR IDispatch support when we
shipped 2.0 which is the reason why we added the -X:PreferComInteropAssembly
command line option. The DLR team has spent more time improving the COM
interop support and validating that it's compatible w/ old VB/VBA semantics
since then and we're more confident that it'll be quite usable for 2.6. But
neither option is really designed to be code compatible w/ pywin32.
This is something we could certainly push on in the future and I'd encourage
you to open a bug on IronPython.CodePlex.com (and others to vote on it) if COM
compat w/ CPython is important.
From: [email protected]
[mailto:[email protected]] On Behalf Of Luke Graybill
Sent: Friday, May 15, 2009 2:40 PM
To: [email protected]
Subject: [IronPython] can anyone help me with COM access in ironpython?
I've got a working example using the pywin32 extensions, which I am trying to
duplicate in IronPython, but I'm encountering quite a number of strange
situations. I can't seem to find any real documentation for IronPython, either,
so I figure this list is my last place to go before I ditch IronPython and just
use pywin32 instead.
Anyway, here is the pywin32 code: http://dpaste.org/aZpE/
The crucial part there is where the COM object (QBXMLRP2.RequestProcessor) is
used. IronPython does seem to allow me to use the same object for some reason,
forcing me to select a different one, as you'll see here:
http://dpaste.org/rIzF/
What am I missing here? Specifically,
1) Why does the exact same COM object function differently (and ultimately
fail) when used through IronPython?
2) Why are different methods exposed on the COM object through IronPython's clr
module, than when the COM object is used through pywin32's client dispatch?
3) Why do I need to refer the the COM object as Interop.QBXMLRP2 in IronPython,
but simply as QBXMLRP2 in pywin32?
I'm missing something fundamental here, please enlighten me! :)
Thanks!
--
Visit me @ http://killarny.org
_______________________________________________
Users mailing list
[email protected]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
