It was well encapsulated indeed, no question. Sometimes I forget that the roots of most of the vfp/xbase commands and syntax were instituted a long, long time ago - at least by computer standards. Had I not queried the value externally I probably still would not have noticed.

I think I will just flip the digits like this:
x = '0x' + ;
RIGHT(TRANSFORM(_screen.BackColor, '@0'),2) + ;
SUBSTR(TRANSFORM(_screen.BackColor, '@0'),7,2) +;
SUBSTR(TRANSFORM(_screen.BackColor, '@0'),5,2)

if I have to externally query a VFP color property.

>>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.
>
>Fox was always doing some things differently, but looking at it historically, it came about because it did them before the standards were set. It had to have its own window management, because of the mac version which predates the windows version for a few years. FP 1.0 came before W3, FPW came at the time of W3.1. I guess only dr Dave could shed some light. Garry Nietz's book that I have is left with my daughter back in Virginia, and it's been thirteen years since I read it, so I can't know for sure.
>
>You must confess that this quirk was well encapsulated, or else you would have noticed it a decade ago.