Variant and uint64

[Michael Mattias]

>demonstrate the fallacy of your statement,

I made no statement other than that of a belief, a belief which since been shown mistaken.

My point was, when 'something' returns a VARIANT - by whatever means - the PROGRAMMER is responsible for interrogating the data type (VARIANTVT()) and effecting any conversion to the datatype required in his/her program. It is simply not reasonable to expect the compiler to know that a VT_BSTR is a valid datatype suitable for conversion to a numeric variable using the VARIANT#() function, simply because this time that BSTR just happens to contain something which could be interpreted as a character zoned decimal number.

Then again, maybe you think it is reasonable, in which case you should submit the New Feature Suggestion to which I alluded earlier in this thread.

MCM

[Dominic Mitchell]

(While I am doing this, you should make a note that VARIANT#() also does not handle VT_DECIMAL types,
but there is code here to handle that for you). (Yes, I have submitted a new feature suggestion for same).

Then again, maybe you think it is reasonable, in which case you should submit the New Feature Suggestion
to which I alluded earlier in this thread.

Huh!? How is that going to help here?

The documentation is correct. The value is converted to a VT_BSTR because 64-bit integers are not
supported by Automation. See the table below.
Also, see info at the following link(click the numbers link):
http://msdn.microsoft.com/en-us/libr...16(VS.85).aspx

' Variant type 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_EMPTY            [V]   [P]     nothing
'  VT_NULL             [V]   [P]     SQL style Null
'  VT_I2               [V][T][P][S]  2 byte signed int
'  VT_I4               [V][T][P][S]  4 byte signed int
'  VT_R4               [V][T][P][S]  4 byte real
'  VT_R8               [V][T][P][S]  8 byte real
'  VT_CY               [V][T][P][S]  currency
'  VT_DATE             [V][T][P][S]  date
'  VT_BSTR             [V][T][P][S]  OLE Automation string
'  VT_DISPATCH         [V][T][P][S]  IDispatch *
'  VT_ERROR            [V][T][P][S]  SCODE
'  VT_BOOL             [V][T][P][S]  True=-1, False=0
'  VT_VARIANT          [V][T][P][S]  VARIANT *
'  VT_UNKNOWN          [V][T]   [S]  IUnknown *
'  VT_DECIMAL          [V][T]   [S]  16 byte fixed point
'  VT_RECORD           [V]   [P][S]  user defined type
'  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 short
'  VT_I8                  [T][P]     signed 64-bit int
'  VT_UI8                 [T][P]     unsigned 64-bit int
'  VT_INT              [V][T][P][S]  signed machine int
'  VT_UINT             [V][T]   [S]  unsigned machine int
'  VT_VOID                [T]        C style void
'  VT_HRESULT             [T]        Standard return type
'  VT_PTR                 [T]        pointer type
'  VT_SAFEARRAY           [T]        (use VT_ARRAY in VARIANT)
'  VT_CARRAY              [T]        C style array
'  VT_USERDEFINED         [T]        user defined type
'  VT_LPSTR               [T][P]     null terminated string
'  VT_LPWSTR              [T][P]     wide null terminated string
'  VT_FILETIME               [P]     FILETIME
'  VT_BLOB                   [P]     Length prefixed bytes
'  VT_STREAM                 [P]     Name of the stream follows
'  VT_STORAGE                [P]     Name of the storage follows
'  VT_STREAMED_OBJECT        [P]     Stream contains an object
'  VT_STORED_OBJECT          [P]     Storage contains an object
'  VT_BLOB_OBJECT            [P]     Blob contains an object
'  VT_CF                     [P]     Clipboard format
'  VT_CLSID                  [P]     A class ID
'  VT_VECTOR                 [P]     simple counted array
'  VT_ARRAY            [V]           SAFEARRAY*
'  VT_BYREF            [V]           void* for local use
'  VT_BSTR_BLOB                      Reserved for system use

[Michael Mattias]

The documentation is correct. The value is converted to a VT_BSTR because 64-bit integers are not

Huh? I never said anyone's doc was wrong. I said PB VARIANT#() does not convert type VT_DECIMAL, which I believe qualifies as a "numeric" variant data type.

And so what automation doesn't support 64 bit integers? Totally irrelevant!

What is at issue here is, should...

Z = VARIANT#(variant_Var)

.. return anything other than zero when the VARIANTVT(variant_var) equals VT_BSTR?

That is, dare it assume the BSTR is a character zoned decimal?

I don't think so. You may disagree.

MCM

[Michael Mattias]

The value is converted to a VT_BSTR because 64-bit integers are not supported by Automation.

By the way, this is not a universal truth.

The Oracle DB returns NUMBER(11,0) columns thru ADO using the Oracle OLE provider as a VT_DECIMAL.

MCM

[Dominic Mitchell]

And so what automation doesn't support 64 bit integers? Totally irrelevant!

It is very relevant to the original question because it explains why the return value is VT_BSTR.

I don't see what relevance your discussion about what is and is not expected of Variant# has to the original question.
By the way, COM provides the VariantChangeType/VariantChangeTypeEx functions that allow a programmer to change the data type of a variant.

Huh? I never said anyone's doc was wrong.

That was directed at José.

By the way, this is not a universal truth.

The Oracle DB returns NUMBER(11,0) columns thru ADO using the Oracle OLE provider as a VT_DECIMAL.

Authors handle this automation limitation differently. VT_DECIMAL is automation-compatible, VT_UI8 is not.

[Michael Mattias]

I don't see what relevance your discussion about what is and is not expected of Variant# has to the original question.

????

Sentence One, Post One, this thread:

How do I retrieve an unsigned quad (UINT64) from a Variant? I tried several things and they all return '0'... For instance Variant#(MyVariant) also returns '0'. Do I need to use VariantVT() somehow?

Call me crazy, that sure reads as though the original question was about what should be expected of VARIANT#(). The stuff about "Call @@var" and The Sacred and Holy Mysteries of Automation Datatypes was interesting, but I don't think it got an answer.

My answer - in case it got lost in the shuffle here - was "yes, you DO need to use VARIANTVT, and don't go calling that a compiler problem because you were the one who asked to receive a VARIANT datatype in your code."