>>Hi,
>>
>>All grids of my app are built from configuration tables (.DBF tables). That is, using data-driven approach.
>>I decided to add a backcolor specification for various columns. I can do it one of two ways:
>>1. Add a field BACK_COLOR to the configuration DBF and enter a number there (at design time). For example, for the color 128,255,255, the value would be 16777088 (using RGB() function at design time)
>>2. Add fields BC_RED, BC_GREEN, RD_BLUE and enter the values for each color (e.g. 128, 255, 255) and then the application code will set the grid back color using RGB() function at run time
>>
>>Which of the above is a better practice, in your opinion?
>
>Since you're building your grids programmatically, from this table, the difference at runtime is negligible, you're doing it once per column - just a simple assignment to a property. Whether it be .backcolor=metagrd.back_color, or .backcolor=rgb(bc_red, bc_green, bc_blue) is irrelevant, you're wasting less than millisecond more with the later approach.
>
>I'd still prefer the first approach - as we mostly deal with vfp's (wrong-endian) color numbers, not individual rgb components. With rgb components, at design time you have to split the value to store it, then put it together at runtime, and I see no gain in doing so.

Thank you so much for your input. I will probably follow your suggestion (unless someone gives me a compelling reason otherwise). The only reason, I thought, for using a separate number in the configuration file is that it would be "easier" to guess the actual color by looking at the number. Instead of looking at the total number derived from the RGB() function.