> > > > > > Does the error above show with some certainty that > > > it's a problem with the COM object? > > > > Sadly it doesn't demonstrate much with any > > certainty! > > Humm... Is there a way to debug the python side more > carefully? E.g., using a lower-level interface in the > pythoncom module or something?
At this stage the problem is more confusion as to exactly what is happening. My understanding is: * Their type-library defines that method as having a variant type of VT_LPSTR. * Microsoft declares in wtypes.h that VT_LPSTR is valid in a typedesc, but *not* in a VARIANT. * When Python processes the typelib, it makes no attempt to translate VT_LPSTR to a type that is valid in a Variant. * When Python is making the call to the COM object, it sees that VT_LPSTR - but as it is filling a VARIANT, it gives that error (the error could be clearer - but that is the underlying reason for that type not being supported) The last experiment I asked you to perform should have translated the VT_LPSTR from the typelib into a VT_BSTR - the "standard" string type - but that still failed. You may also like to change the 30 to 12 (VT_VARIANT) and see if that helps. But ultimately, I need to know exactly what variant type the COM object is expecting, and why it fails if a VT_BSTR variant is supplied. There is no general mechanism for debugging this variant conversion process, but that code is fairly stable, so I'm confident that Python is providing a variant that matches the "type tuple" presented to InvokeTypes. In this example it is the COM object itself that is raising the exception. Assuming that modified tuple was passed to InvokeTypes, I'm confident that a correct VT_BSTR was passed. Cheers, Mark _______________________________________________ Python-win32 mailing list Python-win32@python.org http://mail.python.org/mailman/listinfo/python-win32
