DynamicBackColor with ColorCode, Not RGB(...) 3

[dantheinfoman]

Hi All,

I'm currently storing colors to a field that is numeric using GETCOLOR(). All references to DynamicBackColor talk about using RGB() function. I can't seem to get the actual colorCode to work in the same manner. Does anyone know if this is possible. Here's what I'm trying to no avail:

SET STEP ON
	IF !EMPTY(tk_cntr2.earlycolor)
		PUBLIC m.earlycolor
		m.earlycolor= tk_cntr2.earlycolor  &&eg 255 for red
		THISFORM.grid1.dtin.DynamicBackColor = "iif(ttsched.EarlyArriv=1 or ttsched.LateArriv=1, m.earlycolor,rgb(255,255,255)"
	ENDIF 
	IF !EMPTY(tk_cntr2.latecolor)
		PUBLIC m.latecolor
		m.latecolor = tk_cntr2.latecolor
		THISFORM.grid1.dtou.DynamicBackColor = "iif(ttsched.EarlyDepar=1 or ttsched.LateDepar=1, m.latecolor,rgb(255,255,255)"
	ENDIF

Thanks for any help!

Dan

 

[atlopes]

You can use the value of color controls as literals in the Dynamic expressions, no need to create public variables. Anyway, you have a problem in both expressions: IIF() is not properly closed.

	IF !EMPTY(tk_cntr2.earlycolor)
		THISFORM.grid1.dtin.DynamicBackColor = "iif(ttsched.EarlyArriv=1 or ttsched.LateArriv=1, " + TRANSFORM(tk_cntr2.earlycolor) + ",RGB(255,255,255))"
	ENDIF 
	IF !EMPTY(tk_cntr2.latecolor)
		THISFORM.grid1.dtou.DynamicBackColor = "iif(ttsched.EarlyDepar=1 or ttsched.LateDepar=1, " + TRANSFORM(tk_cntr2.latecolor) + " ,RGB(255,255,255))"
	ENDIF

 

[Mike Lewis]

A colour code is simply an integer. For example, black is 0; red is 255; white is 16777215. Those are the numbers that you use with all colour-related properties.

RGB() is just a function that provides a convenient way of expressing the integer, in terms of its red, blue and green components. So, RGB(255,0,0) is a colour with all red, no blue and no green. RGB(255,0,0) evaluates to 255, which (as stated above) is the colour code for red.

What this means is that the straight integer and the RGB() codes can be used interchangeably. For example:

* These two both set the form to grey
THISFORM.BackColor = 8421504
THISFORM.Back = RGB(128, 128, 128)

* These two have the same effect as each other
THISFORM.MyGrid.Column1.DynamicBackColor = "IIF(llFlag, 8421504, 0)"
THISFORM.MyGrid.Column1.DynamicBackColor = "IIF(llFlag, RGB(128, 128, 128, RGB(0, 0, 0,))"

I hope this makes sense.

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[StefanFoerner]

Hi Dan,

for one and the same color the return values of GETCOLOR() and RGB() are exactly the same!

Also: the function colVal = RGB( nRedValue, nGreenValue, nBlueValue ) simply calculates only the following:

colVal = nRedValue + 256 * nGreenValue + 256 * 256 * nBlueValue

Regards, Stefan

 

[Olaf Doschke]

As antlopes already spotted, your only problem is a missing closing bracket, not the literal vs function return values.

Bye, Olaf.

 

[atlopes]

Dan, after a rereading of your post: if tk_cntr2 refers to a data working area and it is within scope when the Dynamic expression is evaluated, then you can use it at will in your expression (no need to TRANSFORM() it in the process...).

You might consider use [highlight #FCE94F]IF tk_cntr2.earlycolor != -1[/highlight] instead of [highlight #FCE94F]IF !EMPTY(tk_cntr2.earlycolor)[/highlight], since -1 is the value GETCOLOR() returns when no color was selected.

 

[dantheinfoman]

Hi All,

atlopes and Olaf - Thanks, can't wait to try it.

MikeLewis and Stefan - Thanks for the lesson and for expounding on the topic!

also atlopes - I have validation for my colorpicker button to ensure -1 doesn't get into the field. It's either blank or has a color, so as long as it's greater than zero it should be okay, but good catch!

THANKS ALL!

Dan

 

[atlopes]

I have validation for my colorpicker button to ensure -1 doesn't get into the field. It's either blank or has a color, so as long as it's greater than zero it should be okay, but good catch!

I see, since zero can not be selected as a color, that will be the exact opposite of Ford's famous quote: "Any customer can have a car painted any color that he wants so long as it is black."

 

[Olaf Doschke]

...or put in another way: There is no difference from blank and 0, unless you really check for ISBLANK(), but you make use of EMPTY(). The numeric value of BLANK or EMPTY integer fields is 0, though, unless you make it a NULLable field, but then would need ISNULL() to check it. Checking for blank fields is a bad idea, it's only okay for backcolors, if your forecolor/text color is black, you never will want black on black. In general though, don't make use of blankness of fields, it's no real separate state from 0. Either use NULL or -1, as atlopes suggests.

Bye, Olaf.

 

[Mike Lewis]

Actually, there is a slight problem. Although GETCOLOR() returns -1 if the user cancels the dialog, -1 is in fact a legitimate colour code. In fact, all negative 24-bit numbers seem to be valid colour codes. -1 is in fact very close to white.

I've got a vague idea why that should be so, but perhaps somebody else can explain it better than I can.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[atlopes]

Color settings only look at the lower 24 bits of a 32 bit integer and disregard the upper 8. So, since -1 is equal to 0xFFFFFFFF, setting a color to -1 is equal to setting a color to white, that is, 0xFFFFFF / RGB(255,255,255), in the same way that setting a color to -65536, or 0xFFFF0000, will set it to blue, which is 0xFF0000 / RGB(0,0,255).

 

[Mike Lewis]

Thanks, Atlopes. That's exactly the idea that I wanted to explain. You put in words better than I could.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

I didn't know VFP is not strict about this, but you don't lose any color space when not using negative values, so you may denote a non used color with -1, if you don't like NULL. But the concept of BLANK and ISBLANK shouldn't be used.

Bye, Olaf.

 

[atlopes]

If Dan wants to store the result of GETCOLOR() in tk_cntr2.earlycolor and tk_cntr2.latecolor, the only negative number that may occur will be -1, representing "not set" (GETCOLOR() does not return other negative numbers, even if one passes it a negative color number as the starting color). So, checking for -1 would be enough, of course, but NULLifying the fields, as Olaf suggested, would be more meaningful for data representation, and not dependent on GETCOLOR() particular specs.