[python-win32] win32com and extended error messages: IDL with [out, retval] long* error)

Mark Hammond skippy.hammond at gmail.com
Tue Dec 2 04:30:22 CET 2008


Sandy Walsh wrote:
> Hi,
> 
> I have a C++ COM Server with an IDL entry of:
> 
> [
>    object,
>    uuid(D989CB9A-0013-4E1A-BFB6-98A7946BD255),
>    dual,
>    helpstring("IFoo Interface"),
>    pointer_default(unique)
> ]
> interface IFoo : IDispatch
> {
>    [ id(1), helpstring("method Connect")]
>        HRESULT Connect([in] BSTR x, [in] short y, [in] BSTR z, [out, 
> retval] long* error);
> };
> 
> A call from Python to the C++ object works fine unless I return 
> something other than S_OK for "error".

What does the C++ code look like?

>            self.assertEqual(0, self.control.Connect("10.0.0.0", "9999", 
> ""))

That looks strange - your IDL says y is an integer, but you are passing 
a string.

> The call failed with code 80020009: Exception occurred.
> The source of the error is None
> The error message is None
> More info can be found in None (id=0)
> Win32 exception occurred releasing IUnknown at 0x00e84c58
> 
> (where HR of 0x80020009 is DISP_E_EXCEPTION)

So something is returning DISP_E_EXCEPTION as the HRESULT for the method 
(which is quite different than having a dispatch "return value" (which 
is passed as a param to the C++ implementation) named error.

> I've traced the python side of the code and how it appears to me is the 
> "error" out variable is not being created in the argument list.

No - it is a return value: it comes back in the VARIANT holding the 
result.  Note we are going via IDispatch, so something, presumably ATL, 
is converting the IDispatch::Invoke call into a native vtable based call 
into your implementation.

> I'm not sending extended error messages on the C++ side, just setting 
> this error code out variable.

How are you setting it exactly?  And what do you mean by "sending 
extended error messages" - how would they be sent?

 > I can only assume that the exception is
> being generated in the MS Com libraries when it tries to marshal the 
> error variable into a non-existent spot?

I don't think the COM libraries would throw that kind of exception.

Is it possible that your C++ implementation is returning the error code 
instead of setting it?  Your C++ method should always return S_OK, but 
set "error" via a pointer passed to your function.

Cheers,

Mark



More information about the python-win32 mailing list