>Ed, the problem is the ActiveX controls that are out there do not work well with VFP7. Indeed, I am revisiting button background color issue right now with the release of VFP7. In fact I have been waiting for VFP to implement it ever since VFP3, but still no luck! I am wasting the better part of a week evaluating ActiveThreed, itButton, BetterButton, you name it. They all have their shortcomings, and I am finding many properties are inaccessible at development time within the VFP7 IDE. Other parts of the third party components are flaky or don't work quite right compared to VB.
>
>The argument MS makes about non-standard GUI is nonsense. Why does VB6 support it then?
>
>If a programmer purposely changes the BackColor property to an explicit color, I'm sure he knows and intends this color to be consistent throughout his app no matter what the user's Windows desktop color scheme.
>
>End of rant; I develop touchscreen based kiosk applications for a living with VFP and this seemingly simple feature has been a real bug with me for a long time.

I'm not Ed, so PMFJI. The issue with VFP and certain ActiveX controls is caused by the fact that VFP does not follow certain windows design guidelines in terms of message processing and other things. The actual WinProc function that every VFP form uses is the indicated by the main VFP window (sometimes referred to as _SCREEN). This includes both MDI and SDI applications (with SCREEN=OFF in the configuration file).

Internally, VFP does a lot of internal memory management in order to achieve its level of performance. If VFP changed internally to use the standard Windows objects (command buttons are windows in VB, for example, but not VFP) and messaging, you can be sure that it would be at the expense of performance. Not being able to utilize all ActiveX controls is probably, in the overall scheme of thing for the best. Frustrating, yes, but probably for the best.