Tim Roberts wrote:
> Brad Buran wrote:
>> When I generate the interface file for a COM object using makepy, it
>> generates an incorrect signature for one of the methods:
>>
>> def ReadTag(self, Name=defaultNamedNotOptArg,
>> pBuf=defaultNamedNotOptArg, nOS=defaultNamedNotOptArg,
>> nWords=defaultNamedNotOptArg):
>> return self._oleobj_.InvokeTypes(9, LCID, 1, (3, 0), ((8, 0),
>> (16388, 0), (3, 0), (3, 0)),Name
>> , pBuf, nOS, nWords)
>>
>> The C++ signature for the method is (based on a working C++ example
>> provided by the manufacturer):
>>
>> long ReadTag(LPCTSTR Name, float * pBuf, long nOS, long nWords)
>> {
>> long result;
>> static BYTE parms[] = VTS_BSTR VTS_PR4 VTS_I4 VTS_I4 ;
>> InvokeHelper(0x9, DISPATCH_METHOD, VT_I4, (void*)&result, parms,
>> Name, pBuf, nOS, nWords);
>> return result;
>> }
>>
>> My understanding is that 16388 corresponds to VT_R4 (based on an old
>> email thread on this list).
> No. 16388 is 4+16384, which is VT_R4+VT_BYREF. So, this is a
> single-precision float passed by reference -- meaning by pointer.
>
> So, the Python declaration says VT_I4 (return type), VT_BSTR,
> VT_R4+VT_BYREF, VT_I4, and VT_I4. That's mostly correct.
This just occurred to me -- I'll bet that is supposed to be a pointer to
an array of floats, isn't it? Then yes, you have a problem. That's not
the proper way to pass an array in COM. In the dispatch mechanism,
you're supposed to pass it as a safe array structure that contains
sizing information. By declaring a float *, there's no way for the
marshalling mechanism to know how large the array is.
I think you are going to have to use other magic to access this
function. I'm not sure there is any way to coerce makepy into
generating an array of floats to satisfy a float *.
--
Tim Roberts, t...@probo.com
Providenza & Boekelheide, Inc.
_______________________________________________
python-win32 mailing list
python-win32@python.org
http://mail.python.org/mailman/listinfo/python-win32
