Integer literals

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • John Dann

    #1

    Integer literals

    I'm trying to use a third party .Net charting control. One of its
    methods takes a standard 4-byte integer as a parameter (to specify a
    colour actually, but it's done as a standard integer value and not eg
    a colour object). Because the colour will be in ARGB colour space the
    integer needs to specify all four bytes.

    But if I try to pass the integer as eg &HFFCCDDEE then the VB2005
    Intellisense immediately seems to knock this back to &HCCDDEE, which
    is then an incorrect value.

    There are some workarounds I can use involving methods to convert
    between colour spaces (eg starting with color.fromARGB) , but I'm
    curious as to why what seems to be the simple straightforward approach
    of specifying the required integer directly in a 4-byte/8-digit format
    is failing. Is there an alternative syntax that I need to use to
    specify 4-byte values?

    JGD
  • Ken Tucker [MVP]

    #2
    RE: Integer literals

    Hi,

    Maybe ColorTranslator .FromOle will work.

    http://msdn2.microsoft.com/en-us/lib...r.fromole.aspx

    Ken
    ---------------------

    "John Dann" wrote:
    [color=blue]
    > I'm trying to use a third party .Net charting control. One of its
    > methods takes a standard 4-byte integer as a parameter (to specify a
    > colour actually, but it's done as a standard integer value and not eg
    > a colour object). Because the colour will be in ARGB colour space the
    > integer needs to specify all four bytes.
    >
    > But if I try to pass the integer as eg &HFFCCDDEE then the VB2005
    > Intellisense immediately seems to knock this back to &HCCDDEE, which
    > is then an incorrect value.
    >
    > There are some workarounds I can use involving methods to convert
    > between colour spaces (eg starting with color.fromARGB) , but I'm
    > curious as to why what seems to be the simple straightforward approach
    > of specifying the required integer directly in a 4-byte/8-digit format
    > is failing. Is there an alternative syntax that I need to use to
    > specify 4-byte values?
    >
    > JGD
    >[/color]

    Comment

    • Göran Andersson

      #3
      Re: Integer literals

      An Int32 is a signed data type, which means that it can hold the values
      -&H80000000 to &H7fffffff. Therefore &Hffccddee is not a valid value for
      an Int32. You can use the value -3351058 or -&H332212.

      John Dann wrote:[color=blue]
      > I'm trying to use a third party .Net charting control. One of its
      > methods takes a standard 4-byte integer as a parameter (to specify a
      > colour actually, but it's done as a standard integer value and not eg
      > a colour object). Because the colour will be in ARGB colour space the
      > integer needs to specify all four bytes.
      >
      > But if I try to pass the integer as eg &HFFCCDDEE then the VB2005
      > Intellisense immediately seems to knock this back to &HCCDDEE, which
      > is then an incorrect value.
      >
      > There are some workarounds I can use involving methods to convert
      > between colour spaces (eg starting with color.fromARGB) , but I'm
      > curious as to why what seems to be the simple straightforward approach
      > of specifying the required integer directly in a 4-byte/8-digit format
      > is failing. Is there an alternative syntax that I need to use to
      > specify 4-byte values?
      >
      > JGD[/color]

      Comment

      • Jay B. Harlow [MVP - Outlook]

        #4
        Re: Integer literals

        John,
        I am able to use the following in VB 2005.

        Dim hexColor As Integer = &HFFCCDDEE

        If I look at the variable in the hexColor variable in a watch window, it
        contains either &HFFCCDDEE in hex or -3351058

        Are you certain that VB is changing the value & not the control itself?


        I would question the quality of any .NET charting control that didn't use
        System.Drawing. Color to specify color values! As you should need to worry
        about any "workaround s" or how to specify a color...


        --
        Hope this helps
        Jay B. Harlow [MVP - Outlook]
        ..NET Application Architect, Enthusiast, & Evangelist
        T.S. Bradley - http://www.tsbradley.net


        "John Dann" <news@prodata.c o.uk> wrote in message
        news:fk3a92ttr5 39fpqbija4r6l9q f8vref6ld@4ax.c om...
        | I'm trying to use a third party .Net charting control. One of its
        | methods takes a standard 4-byte integer as a parameter (to specify a
        | colour actually, but it's done as a standard integer value and not eg
        | a colour object). Because the colour will be in ARGB colour space the
        | integer needs to specify all four bytes.
        |
        | But if I try to pass the integer as eg &HFFCCDDEE then the VB2005
        | Intellisense immediately seems to knock this back to &HCCDDEE, which
        | is then an incorrect value.
        |
        | There are some workarounds I can use involving methods to convert
        | between colour spaces (eg starting with color.fromARGB) , but I'm
        | curious as to why what seems to be the simple straightforward approach
        | of specifying the required integer directly in a 4-byte/8-digit format
        | is failing. Is there an alternative syntax that I need to use to
        | specify 4-byte values?
        |
        | JGD


        Comment

        • Jay B. Harlow [MVP - Outlook]

          #5
          Re: Integer literals

          Göran,
          | An Int32 is a signed data type, which means that it can hold the values
          | -&H80000000 to &H7fffffff
          Actually it can hold the hex literals &H0 to &HFFFFFFFF; When assigning a
          Hex Literal to an Integer, &H80000000 to &HFFFFFFFF are negative numbers
          representing Int32.MinValue to -1.

          The hex literals are sign agnostic, VB allows the assignment based on the
          number of digits given... (10 hex digits will not fix in an Integer).

          --
          Hope this helps
          Jay B. Harlow [MVP - Outlook]
          ..NET Application Architect, Enthusiast, & Evangelist
          T.S. Bradley - http://www.tsbradley.net


          "Göran Andersson" <guffa@guffa.co m> wrote in message
          news:OlbCEhwkGH A.5108@TK2MSFTN GP02.phx.gbl...
          | An Int32 is a signed data type, which means that it can hold the values
          | -&H80000000 to &H7fffffff. Therefore &Hffccddee is not a valid value for
          | an Int32. You can use the value -3351058 or -&H332212.
          |
          | John Dann wrote:
          | > I'm trying to use a third party .Net charting control. One of its
          | > methods takes a standard 4-byte integer as a parameter (to specify a
          | > colour actually, but it's done as a standard integer value and not eg
          | > a colour object). Because the colour will be in ARGB colour space the
          | > integer needs to specify all four bytes.
          | >
          | > But if I try to pass the integer as eg &HFFCCDDEE then the VB2005
          | > Intellisense immediately seems to knock this back to &HCCDDEE, which
          | > is then an incorrect value.
          | >
          | > There are some workarounds I can use involving methods to convert
          | > between colour spaces (eg starting with color.fromARGB) , but I'm
          | > curious as to why what seems to be the simple straightforward approach
          | > of specifying the required integer directly in a 4-byte/8-digit format
          | > is failing. Is there an alternative syntax that I need to use to
          | > specify 4-byte values?
          | >
          | > JGD


          Comment

          • John Dann

            #6
            Re: Integer literals

            On Sun, 18 Jun 2006 15:18:15 -0500, "Jay B. Harlow [MVP - Outlook]"
            <Jay_Harlow_MVP @tsbradley.net> wrote:
            [color=blue]
            >Are you certain that VB is changing the value & not the control itself?[/color]

            Many thanks for the comments. What I observe is that I can enter a
            value of eg &HFFC0C0C0 as a parameter in a call to a method of the
            charting control. As soon as I move the cursor out of that code line
            in the VB2005 code editor then the value flicks back to &HC0C0C0.
            This is why I referred to it as happening as a result of Intellisense.
            But whether this behaviour is triggered by VB itself or perhaps by the
            variable type exposed by the charting control for the parameter in
            question is I'm afraid beyond me!
            [color=blue]
            >I would question the quality of any .NET charting control that didn't use
            >System.Drawing .Color to specify color values! As you should need to worry
            >about any "workaround s" or how to specify a color...[/color]

            That's probably fair comment. It's actually a control called
            ChartDirector (from www.advsofteng.com/). I suspect the cause is that
            the core of this control is actually compatible with many programming
            languages and it possibly just has a wrapper in its .Net version. So
            some of the variable types may need conversion - I know the
            documentation makes the point that its ARGB implementation follows the
            general HTML/web convention and not the .Net one.

            But that said, in compensation it is excellent value-for-money,
            powerful and flexible, a reasonably easy learning curve (much more so
            than many competitor products), well-supported, produces good quality
            results and seems to run robustly (other than the sort of quirk which
            was the reason for the original post). So you can see why I like to
            use this one!

            JGD

            Comment

            • Larry Lard

              #7
              Re: Integer literals


              John Dann wrote:[color=blue]
              > On Sun, 18 Jun 2006 15:18:15 -0500, "Jay B. Harlow [MVP - Outlook]"
              > <Jay_Harlow_MVP @tsbradley.net> wrote:
              >[color=green]
              > >Are you certain that VB is changing the value & not the control itself?[/color]
              >
              > Many thanks for the comments. What I observe is that I can enter a
              > value of eg &HFFC0C0C0 as a parameter in a call to a method of the
              > charting control. As soon as I move the cursor out of that code line
              > in the VB2005 code editor then the value flicks back to &HC0C0C0.
              > This is why I referred to it as happening as a result of Intellisense.
              > But whether this behaviour is triggered by VB itself or perhaps by the
              > variable type exposed by the charting control for the parameter in
              > question is I'm afraid beyond me![/color]

              It actually changes the code you typed? That's unusual.
              [color=blue][color=green]
              > >I would question the quality of any .NET charting control that didn't use
              > >System.Drawing .Color to specify color values! As you should need to worry
              > >about any "workaround s" or how to specify a color...[/color]
              >
              > That's probably fair comment. It's actually a control called
              > ChartDirector (from www.advsofteng.com/).[/color]

              OK I grabbed the trial version. First things first - as stated in their
              docs, the ARGB format they expect has it's 'A' the other way round from
              ..NET:

              "
              The .NET framework has a class System.Drawing. Color used to represent
              colors. However, its ARGB color representation is not compatible with
              ChartDirector. For example, in System.Drawing. Color, the red color is
              FFFF0000 instead of FF0000. The reason is because the alpha component
              in .NET actually refers to opacity - the reverse of transparency as
              used in ChartDirector.
              "

              So considering the solid grey color we are talking about:

              - In .NET, this color's .ToArgb is &HFFC0C0C0, with the FF representing
              maximum *opacity*
              - In HTML convention, this color would be &HC0C0C0, with the initial 00
              representing zero *transparency*

              This control wants its colors in HTML format, so anything like
              &HFFxxxxxx would be completely *transparent*, so the xxxxxx would be
              irrelevant. Again from the docs:

              "
              If alpha transparency is FF (255), the color is totally transparent.
              That means the color is invisible. It does not matter what the RGB
              components are. So in ChartDirector, only one totally transparent color
              is used - FF000000. All other colors of the form FFnnnnnn are reserved
              to represent palette colors and dynamic colors, and should not be
              interpreted as the normal ARGB colors.
              ....
              For convenience, ChartDirector pre-defines a constant called
              Transparent, which is equivalent to FF000000.
              "

              So this explains the 'why' of it automatically changing the code you
              write, when you try and pass &HFFC0C0C0. This is a 'special' value and
              probably not what anyone typing it means, so it autocorrects it to
              &HC0C0C0, which is probably what is meant. The 'how' is another
              question, which isn't totally relevant so I haven't spent much time
              looking into it.

              I note finally from the docs the existence of helper functions
              (Chart.CColor and Chart.NColor) to convert between the two different
              color representations - these should be used for code clarity.

              --
              Larry Lard
              Replies to group please

              Comment

              Working...