Definitely tsk on me. You confirmed it is a bug though in that the property sheet displays differently than the rgb() function. Or perhaps a feature. But you are right, I never noticed the difference between the property sheet and RGB(). The backwards order violates windows standards and well, is pretty stupid to have property sheet and function behave differently and not document that anywhere. I guess either it never came up or I was living in ignorant bliss (smile). Either way it is bizarre behavior to say the least.

I discovered it when another program queried VFP and asked for a color number and got a backwards number. VFP always lived in its own world, but come on, RGB colors you have to make different than every other program in the world?

Thanks for the explanation.

>>if the decimal number returned by RGB() is using the parameters in backwards order, that is a major bug that contradicts all the VFP docs and common sense. It also is internally contradictory. Using the RGB() function to set a color property works exactly as the docs say and as one would assume - R then G then B. But the RGB() functon returns a completely different number when used not to set a property but as a function to return a value.
>>
>>IOW .backcolor=rgb(204,198,149) shows the correct color. And it returns the correct value. But the function RGB() when used by itself returns a number based on backwards BGR order. That is beyond inexplicable. VFP is really using BGR but internally converts everything in a color property to RGB?
>
>It's been like this for the last 20 years, and now you've noticed? Tsk, tsk...
>
>Try this:
>
>_screen.backcolor=rgb(204,198,149)
>clear
>
>or alternately
>
>_screen.backcolor=9815756
>clear
>
>After either of them, try
>
>?_screen.backcolor, rgb(204,198,149)
>
>You get the same number twice. The function is called RGB, but internally fox always keeps color numbers in BGR order. And yes, the property sheet will display it in RGB order, that's how it was written.