[python-win32] Problem passing a VARIANT argument to a method of aCOM object

[Mark Hammond]

> > >
> > > 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