Logo

Hacker’s Guide to Visual FoxPro
An irreverent look at how Visual FoxPro really works. Tells you the inside scoop on every command, function, property, event and method of Visual FoxPro.

GETCOLOR()

This function brings up the Windows Color Picker dialog and returns the color chosen.

Usage

nColor = GETCOLOR ( [ nDefaultColor ] )

Parameter

Value

Meaning

nDefaultColor

Numeric

A number from 0 to 16,777,215 representing the default color to be highlighted in the Color Picker.

nColor

-1

The user pressed Esc or clicked Cancel.

0 - 16,777,215

The number of the color chosen by the user.

We found a number of nits to pick in the behavior of this dialog (in particular, when it’s expanded to allow custom colors), but since this is a Windows common dialog, we can’t blame the Visual FoxPro developers, so we won’t yell too loud here. After all, this is a Visual FoxPro book, not a Windows book. But here’s our laundry list of problems with GETCOLOR().

First, if the initial color is black, you’ll notice that the RGB values shown in the expanded dialog are all 0. Click all you want in the big color rectangle and the RGB values don’t change until you click somewhere in the narrow bar off to the right. You see a similar problem if the initial color is white. A Microsoftie tried to explain this to us as correct behavior, but it’s just plain weird.

If you add a color to custom colors, then close the dialog, open it again, and add another color, it overwrites the first one. You have to remember to click the place you’d like the new color to land on the palette to avoid this, but then you have to go back and click the color you want to start with. All in all, adding custom colors is a usability nightmare.

Even without fiddling with custom colors, there’s some pretty strange behavior. If you pass in a color that isn’t in the palette, the dialog opens with the first color in the dialog highlighted, regardless of its relationship to the color you specified. (In Win 3.x, we’re pretty sure it at least tried to approximate the color you wanted, but we don’t have any 3.x machines left to test on.) If you then click OK, you get back the color value you passed instead of the highlighted color. Among other things, this means you see the same color highlighted, but get back an assortment of different values. Or, put another way, in any given call, you see one color highlighted, but the return value is a different color.

All in all, we think it’s way past time the OS group got around to overhauling this dialog.

If you do pass a number in, remember that you can’t just send three values between 0 and 255. Use RGB() to combine them into a single color value.

The number that GETCOLOR() returns is a single integer between -1 and 256^3. The procedure below lets the user choose a color, then returns separate red, green and blue values.

Example

* ParsColr.PRG
* Get a color and Parse it into its RGB components.
* Set all three to -1 if the user cancels.
* This is a native code alternative to the FoxTools
* RGBComp() function.
* Sample call:
*     STORE -1 TO nRed, nGreen, nBlue
*     DO ParsColr WITH nRed,nGreen,nBlue

LPARAMETERS nRed, nGreen, nBlue

LOCAL nColor

nColor = GETCOLOR()

IF nColor<>-1  && user didn't cancel
   nBlue  = INT(nColor/(256^2))
   nColor = MOD(nColor,(256^2))
   nGreen = INT(nColor/256)
   nRed   = MOD(nColor,256)
ELSE
   STORE -1 to nBlue, nGreen, nRed
ENDIF

RETURN

See Also

FoxTools, RGB()