Integer literals

  • Thread starter Thread starter John Dann
  • Start date Start date
J

John Dann

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
 
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,
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 "workarounds" 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


| 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
 
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


| 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
 
Are you certain that VB is changing the value & not the control itself?
Click to expand...

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!
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 "workarounds" or how to specify a color...
Click to expand...

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
 
John said:
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!
Click to expand...

It actually changes the code you typed? That's unusual.
That's probably fair comment. It's actually a control called
ChartDirector (from www.advsofteng.com/).
Click to expand...

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.
 
Back
Top