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

Reply via email to