On 17/02/2009 6:17 PM, Shaer, Neta wrote:
Hello,

I’m using python 2.5 on windows (32 bit).

I'm using some COM object from python.
One of the functions in this COM objects expects VARIANT and operate
according to the type of this VARIANT.
The thing is that it does one thing if the VARIANT type is VT_UI4 (32
bit integer) and a different thing for VARIANT of type VT_UI8 (64 bit
integer).
The python code that calls this function 'knows' what should be the type
of the VARIANT. and in certain cases, the type of the VARIANT should be
VT_UI8 (64 bit), though the actual value of the variable is small (i.e.
can be contained in 32 bit). But in these cases python will
automatically set the type of this variant to VT_UI4 and this will cause
the COM function to do the wrong thing (and eventually fail).
Is there any way to 'force' python to pass this VARIANT as VT_UI8 though
its value is very small?

No - infact pywin32 doesn't support VT_UI8 at all - but it will use VT_I8 only when the value doesn't fit in 32 bits. Note that MS documents *both* VT_I8 and VT_UI8 as being an invalid type in a variant:

from WTypes.h:

* VARENUM usage key,
 *
 * * [V] - may appear in a VARIANT
 * * [T] - may appear in a TYPEDESC
 * * [P] - may appear in an OLE property set
 * * [S] - may appear in a Safe Array
 ...

 *  VT_I1               [V][T][P][s]  signed char
 *  VT_UI1              [V][T][P][S]  unsigned char
 *  VT_UI2              [V][T][P][S]  unsigned short
 *  VT_UI4              [V][T][P][S]  unsigned long
 *  VT_I8                  [T][P]     signed 64-bit int
 *  VT_UI8                 [T][P]     unsigned 64-bit int

So it would appear our support for even VT_I8 is suspect. To make matters less clear, we only support VT_I8 when *creating* a variant - we do not attempt to unpack VT_I8 or VT_UI8 from an incoming variant at all - in general we only support those explicitly declared by MS to be valid in variants (although there is almost no risk in accepting unsupported types on the way in that I can see)

BTW: it wouldn't be hard to argue that the COM object in question is insane - that the size of the integer passed shouldn't impact how it operates - but I guess it is what it is...

Cheers,

Mark
_______________________________________________
python-win32 mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-win32

Reply via email to