Re: [python-win32] Fixing type ID for an interface file generated by makepy
Ok! I'll install Visual Studio and see if I can make any headway.
Thanks for your help!
Brad
On Wed, Jan 26, 2011 at 5:44 AM, Graham Bloice
graham.blo...@trihedral.com wrote:
On 25/01/2011 06:44, 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). However, it should be a type code that
corresponds to VTS_PR4. I have hunted all over the internet (Google,
Bing, etc) and cannot find the correct number that I need to plug in
for VTS_PR4 to fix the signature in the interface file. The closest I
can find is this website,
http://msdn.microsoft.com/en-us/library/cc237865%28PROT.13%29.aspx.
However, it does not list VTS_PR4 (not to mention that 16388 is not in
the list either).
I would really appreciate any guidance in 1) figuring out the best way
to fix the signature or 2) finding a more comprehensive list of the
actual constant the type codes corresponds to.
Originally sent to the OP instead of the list. sorry for that.
The numbers in the type code are the bit flags from the variant type
enumeration
(http://msdn.microsoft.com/en-us/library/cc237865%28PROT.13%29.aspx).
16388 equates to 0x4004 which is VT_BYREF | VT_R4 which is correct for the
second parm of the function float * pBuf).
IMHO the C++ example is misleading with the notation VT_PR4 which I've never
come across before. If you have access to it (usually via a Visual Studio
install) the OLE-COM object viewer tool is very useful for spelunking into
type libraries.
--
Regards,
Graham Bloice
___
python-win32 mailing list
python-win32@python.org
http://mail.python.org/mailman/listinfo/python-win32
___
python-win32 mailing list
python-win32@python.org
http://mail.python.org/mailman/listinfo/python-win32
Re: [python-win32] Fixing type ID for an interface file generated by makepy
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
Re: [python-win32] Fixing type ID for an interface file generated by makepy
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.
Yes! That's what it is supposed to be (no wonder I wasn't able to
find it on Google, I assumed that VTS_PR4 was a standardized
constant). The manufacturer has acknowledged that they set it up
wrong, but it's unlikely they'll fix it.
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 *.
Hmm. As in abandoning win32com.Client and writing a Cython wrapper?
The function in question (ReadTag) takes both a pointer to an array of
floats plus a parameter, nWords, that indicates the size of the array.
Perhaps I could do something like this:
from array import array
a = array('f', [0, 0, 0, 0, 0])
iface = win32com.Client('RPco.X')
# last parameter to method is array size
iface.ReadTag('data', a, 0, len(a))
len(a) would provide the information the COM object needs about the
array size. However, when I attempt this code, I get the following
error:
*only length-1 arrays can be converted to Python scalars*
I'm a bit stumped at this point. Is there an easy way to marshal the
array into the right format needed?
Brad
___
python-win32 mailing list
python-win32@python.org
http://mail.python.org/mailman/listinfo/python-win32
