I've put print statements in the python code, printf in the C++
code. What does the OLE error refer to? How can I go further
in debugging the problem?
Thanks
<python code>
def _ApplyTypes_(self, dispid, wFlags, retType, argTypes, user,
resultCLSID, *args):
#win32dbg.set_trace()
print 'self = ',self
print 'dispid = ',dispid
print 'wFlags = ',wFlags
print 'retType = ',retType
print 'argTypes = ',argTypes
print 'user = ',user
print 'resultCLSID = ', resultCLSID
#print '*args = ', *args
return
self._get_good_object_(apply(self._oleobj_.InvokeTypes, (
dispid, LCID, wFlags, retType, argTypes) + args), user, resultCLSID)
<output>
self = <win32com.gen_py.simple 1.0 Type Library.ISimpleObj>
dispid = 13
wFlags = 1
retType = (9, 0)
argTypes = ((8, 1), (8, 1), (8, 1), (8, 1), (3, 1), (8, 1), (3, 1))
user = ConnectServer
resultCLSID = {F8927806-F5D0-11D1-97C7-080009F0F204}
CSimpleObj::ConnectServer <printf from com server>
Traceback (innermost last):
File "<stdin>", line 1, in ?
File "simple.py", line 210, in ConnectServer
return self._ApplyTypes_(0xd, 1, (9, 0), ((8, 1), (8, 1), (8, 1),
(8, 1), (3, 1), (8, 1), (3, 1)), 'ConnectServer',
'{F8927806-F5D0-11D1-97C7-080009F0F204}'
, b1, b2, b3, b4, l5, b6, l7)
File "simple.py", line 47, in _ApplyTypes_
return self._get_good_object_(apply(self._oleobj_.InvokeTypes,
(dispid, LCID, wFlags, retType, argTypes) + args), user, resultCLSID)
pywintypes.com_error: (-2147217400, 'OLE error 0x80041008', (0, None,
None, None, 0, -2147217400), None)
>>>
A guess could the that COM itself is getting in the way. Eg, the C++ object
may be free-threaded, but not support marshalling. If Python is apartment
threaded, this could be the problem.
Try setting "sys.coinit_flags = 0" before pythoncom is first imported.
Also, try using "o=win32com.client.dynamic.Dispatch(clsid)" to avoid the
"makepy" generated code - see if this helps (although I doubt it!)
Also, there should be no problem passing NULL anywhere? Id like to see some
more details on that...
Mark.
Bruce Wheeler wrote in message <35E87E10...@hp.com>...
didn't help
> Also, try using "o=win32com.client.dynamic.Dispatch(clsid)" to avoid the
> "makepy" generated code - see if this helps (although I doubt it!)
couln't get this to work, tryed to map the Excel.Application example
to my com object. I used the VB Browser to retrieve info aboout excel
and then did the same thing for SimpleObj
got this traceback
>>> s = win32com.client.dynamic.Dispatch("SIMPLELib.SimpleObj")
Traceback (innermost last):
File "<stdin>", line 1, in ?
File "C:\Program Files\Python\win32com\client\dynamic.py", line 64, in
Dispatch
IDispatch = _GetGoodDispatch(IDispatch, clsctx)
File "C:\Program Files\Python\win32com\client\dynamic.py", line 55, in
_GetGoo
dDispatch
IDispatch = pythoncom.CoCreateInstance(IDispatch, None, clsctx,
pythoncom.II
D_IDispatch)
pywintypes.com_error: (-2147221005, 'Invalid class string', None, None)
>
I had hoped that having some basic concepts of how COM worked, I could
map the
examples used in QuickStartClientCom to the com objects I have here. And
get
enough to work that I could build on my knowledge of python, win32com.
This hasn't
worked. My approach now is to create the clients in C++ - ugh. Then I'll
try to emulate
the functionality in python. At some point I'll either figure out how to
get win32com
to work with the com objects I have here, or have enough developed with
C++ that I
no longer need python. I cann't use VB as a starting point, since the
com objects I'm working
with don't provide an automation interface. I really hope that I can
figure out the
issues with win32com, since it appears to be excatly what I need.
> Also, there should be no problem passing NULL anywhere? Id like to see some
> more details on that...
I'll provide this if I can make any progress with win32com. I had sent
you a message
re problems with win32-107 build that mentioned the error message
"argument is not a COM
object" that I was trying to chase down.
Bruce
It certainly sounds like your COM object is not working correctly. At least
not registered correctly.
>no longer need python. I cann't use VB as a starting point, since the
>com objects I'm working
>with don't provide an automation interface. I really hope that I can
>figure out the
>issues with win32com, since it appears to be excatly what I need.
Eeek - I think you may have it a little back to front here. It is far more
likely you cant use it with Python at this stage. Unless the interfaces it
uses are explicitely supported by Pythoncom, then you are out of luck. VB
does better with non automation interfaces than Python does. Greg Stein is
working on fixing that! If the COM object doesnt have a type library, then
VB wont work either.
>I'll provide this if I can make any progress with win32com. I had sent
>you a message
>re problems with win32-107 build that mentioned the error message
>"argument is not a COM
>object" that I was trying to chase down.
Your mail is probably still in my inbox - I get lots and lots of support
email, and at the same time Im trying to pay the rent. This "free support"
I give out actually costs _me_ quite a bit. This is going to have to change
in the near future :-(
Mark.