why is this Blue? .BackColor = &HFF0000

[WDSnews]

When I use this,
.BackColor = &HFF0000
I get blue rather than red. I wondered if maybe my system was set to 32 bit
color rather than 24 bit and somehow that makes a difference, but this gives
me the expected white as it should,
.BackColor = &HFFFFFF

I'm going ahead with the RGB function rather than straight hex, but hoping
someone can explain why the straight hex pairs aren't following the familiar
RGB pattern.

 

[Allen Browne]

An RGB value is a 24-bit number, where the least significant byte is the Red
value, and the most significant value is the Blue value. As with decimal
numbers, hex numbers have the least significant digit on the RIGHT, not on
the left.

This means that the RGB value for vbRed is &H0000FF (since the least
significant byte is on the right), and that's what you have to assign
programmatically if you don't want the RGB() function calculating the values
for you.

What's confusing is that the RGB values in some text-based systems (such as
HTML) place the digits the other way around, i.e. the least-significant pair
is on the left. That's not how hexadecimal math works, but it kinda makes
sense for users of a text-based system. Access 2007 allows you to set the
color properties like that, i.e. you could set the ForeColor of a text box
to #FF0000 for red.

Give it a shot. Set the ForeColor of Text0 on Form1 to #FF0000. Then ask VBA
to show you that as hexadecimal digits, by opening the Immediate Window
(Ctrl+G) and entering:
? Hex(Forms!Form1!Text0.ForeColor)

 

[WDSnews]

I can't make sense of what you're telling me. BTW, I've been setting RGB
colors since the Windows 2.0 days when several companies introduced some
creative graphics apps to overcome the Palette focus back then. I've been
using Hex codes for over 30 years. I'll never be able to look at an A
without seeing a 1010. Least significant digits are always on the right.

If 0000FF is red due to RGB being assigned backwards, then 00FF00 should be
green, but it comes out a muddy dark color. I had already considered the
possiblity that some short-sighted engineer had assigned the colors
backwards, but the muddy color for 00FF00 makes it obvious that something
else is going on.

How do you use #0000FF in a .color statement? I get an error unless I use
&H0000FF.

 

[Douglas J. Steele]

There is a built-in RGB function you can use.

For Red, you'd use RGB(255, 0, 0), which equals 255.

For Green, you'd use RGB(0, 255, 0), which equals 65280

For Blue, you'd use RGB(0, 0, 255), which equals 16711680

 

[Allen Browne]

Here it is in decimal:
Dim btRed as Byte
dim btGreen as Byte
dim btBlue as Byte
Dim lngColor As Long
btGreen = 255
lngColor = CLng(btRed) + CLng(btGreen) * 2^8 + CLng(btBlue) * 2^16
If lngColor = RGB(btRed, btGreen, btBlue) Then MsgBox "Yep"

The difficulty with Hex is that VBA performs automatic typecasting, which
messes this up. In the Immediate Window (Ctrl+G), try:
? RGB(0,255,0)
? Hex(RGB(0,255,0))
? Val("&H" & Hex(RGB(0,255,0)))

It doesn't match. That's because VBA treats &HFF00 as a signed short integer
(i.e. -256), not as an unsigned Long (i.e. 65280.) To verify:
? TypeName( &H0000FF00)

 

[WDSnews]

It doesn't match. That's because VBA treats &HFF00 as a signed short

integer (i.e. -256), not as an unsigned Long (i.e. 65280.)

That's it! Thank you. I've been using the RGB function all along. I was
just hoping a &HFF00 could be a simpler solution. It seems clng(&HFF00) is
slightly simpler than rgb(0,&HFF,0), but I think I'll stick with the
improved readability of rgb.

Thanks for the explanation.