>>Whoops got that backwards. It should be:

lntemp = lncolor
>>lnmask = 255
>><b>lnred</b> = BITAND(lntemp, lnmask)
>>lntemp = BITRSHIFT(lntemp, 8)
>>lngreen = BITAND(lntemp, lnmask)
>>lntemp = BITRSHIFT(lntemp, 8)
>><b>lnblue</b> = BITAND(lntemp, lnmask)

>>Same goes for my orignal statement: red's the least significant 8 bits, blue's the most. Doh!
>
>
>>> Doh!
>^ that is definateley me on this issue.

We all go through this at one time or another.

>I think you wrote an article on BIT*() functions. Fundamentally I understand what is going on however I have never had a need to use them so I do not really understand what is going on. I can take your examples and work with it and get where I need to be.

Yes, I did and it was mentioned in another recent article in FoxPro Advisor. The bit manipulation functions are very powerful and can allow you to do somethings very easily that otherwise would be rather difficult.

>At the moment time constraints will probably force me to use FOXTOOLS and handle everything properly during install and init of the app. I can get around my problem another way, it is just not as bullet proof.

Foxtools is an important part of my tool set. Prior to 6.0, I used the JUSTSTEM(), ADDBS(), etc. functions from it all the time. Since then I've found a great deal of utility in the string parsing functions (Words(), WordNum(), StrFilter(), etc.). You might be interested in downloading my "Extended Foxtools Help File" (under Coding, Syntax and Commands). It documents everything in Foxtools and is completely cross-referenced.

>Thank you very much for your input. It looks like we need (maybe just I) a good VFP internal REVERSE color function.

If you're interested, here's the math:

* lncolor is the color of interest
lntemp = lncolor
lnblue = INT(lntemp / (2 ^ 16))
lntemp = lntemp - (lnblue * (2 ^ 16))
lngreen = INT(lntemp / (2 ^ 8))
lnred = lntemp - (lngreen * (2 ^ 8))