> I do not know where you see the VT_VARIANT.
>
> Here is the IDL defn:
>
> [id(0x80010452)]
> VARIANT_BOOL FireEvent(
> [in] BSTR bstrEventName,
> [in, optional] VARIANT* pvarEventObject);
>
> and the comtypes wrapper snippet:
> DISPMETHOD([dispid(-2147417006)], VARIANT_BOOL, 'FireEvent',
> ( ['in'], BSTR, 'bstrEventName' ),
> ( ['in', 'optional'], POINTER(VARIANT),
> 'pvarEventObject' )),
Yeah - when win32com gets the type info, it is told the variable is a
"VT_BYREF|VT_VARIANT - eg:
def FireEvent(self, bstrEventName=defaultNamedNotOptArg,
pvarEventObject=defaultNamedOptArg):
return self._oleobj_.InvokeTypes(-2147417006, LCID, 1, (11,
0), ((8, 1), (16396, 17)),bstrEventName
, pvarEventObject)
16396, 17 == (VT_BYREF|VT_VARIANT, PARAMFLAG_FOPT|PARAMFLAG_FIN)
so pythoncom's type converter sees this type tuple, and tries to create a
variant with the exact type specified. It would seem I must treat
VT_VARIANT as a special case (the returned vartype in that case can be
anything and is driven by the type of the param)
> > Is that correct? If so, I guess I should give that a whirl and
> > hope nothing else in the test suite breaks ;)
>
> Thats what test suites are for...
I'm more worried that the change will break something that some obscure
program relies on (ie, I hope the test suite shows the change is backwards
compatible)
> PS: Do you know the answer to the question that I posted in the other
> reply to this
> thread (short version: does pywin32 use IDispatchEx)?
It doesn't in win32com.client (ie, not when calling objects, as in this
example). win32com.server does IDispatchEx though (mainly as IE itself is
one of the only IDispatchEx users around. IDispatchEx was desgined for
ActiveScripting to offer javascript style semantics to an IDispatch-ish
interface.
Cheers,
Mark
_______________________________________________
python-win32 mailing list
python-win32@python.org
http://mail.python.org/mailman/listinfo/python-win32
