Ignorant ColorDialog API?

[Backslider]

I hope I am wrong.. but it seems like the CustomColors property of the
.NET ColorDialog is not compatible with the ToARGB function of the
Color struct. Could this possibly be true? The documentation says
"Users can create their own set of custom colors. These colors are
contained in an Int32 composed of the ARGB component (alpha, red,
green, and blue) values necessary to create the color."
But if I set one of the entries to Color.Red.ToARGB() it does not
work. The stupid thing seems to want 255 for Red.

I can't imagine what they were thinking when they did this. It makes
no sense to require an ARGB value in a different order in two
different places. So now I have to convert it back and forth?
Unbelievable.

(I really hope I'm wrong)

Backslider

[Bogdan Ledwig]

Windows uses BGR (0x00BBGGRR) ordering for color values (except GDI+ which
is used by .NET). The GDI+ Color type uses 0xAARRGGBB.
You can convert the Color to COLORREF using the code below:

public static int ColorToColorref(Color clr)
{
return (clr.R + (clr.G << 8) + (clr.B << 16));
}

Obviously the documentation is wrong here (or maybe it's rather a bug in the
framework?).

BL

"Backslider" <backs...@mail.com> wrote in message
news:c3c92182.0210...@posting.google.com...

[Backslider]

Bottom Line - The ColorDialog is a .NET Form. It takes color
information in two not-very-compatible ways. If you're setting the
color, you use a Color object, which returns the bits as ARGB. But
then when you set CustomColors, you have to switch them around to BGR.
It is EXTREMELY stupid that everyone who uses the dialog will have to
have that same bit of code in their application. If everybody has to
write it everytime, it should be part of the dialog.

Backslider

"Bogdan Ledwig" <bogd...@hotmail.com> wrote in message news:<OZDF2#GfCHA.1768@tkmsftngp11>...