Announcement

Collapse
No announcement yet.

Variant and uint64

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    >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
    Michael Mattias
    Tal Systems (retired)
    Port Washington WI USA
    [email protected]
    http://www.talsystems.com

    Comment


    • #22
      (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

      Code:
      ' 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
      Dominic Mitchell
      Phoenix Visual Designer
      http://www.phnxthunder.com

      Comment


      • #23
        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...
        Code:
        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
        Tal Systems (retired)
        Port Washington WI USA
        [email protected]
        http://www.talsystems.com

        Comment


        • #24
          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
          Michael Mattias
          Tal Systems (retired)
          Port Washington WI USA
          [email protected]
          http://www.talsystems.com

          Comment


          • #25
            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.
            Last edited by Dominic Mitchell; 2 Oct 2009, 08:35 PM.
            Dominic Mitchell
            Phoenix Visual Designer
            http://www.phnxthunder.com

            Comment


            • #26
              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."
              Michael Mattias
              Tal Systems (retired)
              Port Washington WI USA
              [email protected]
              http://www.talsystems.com

              Comment

              Working...
              X