>>>>So how come VB can do it?
>>>
>>>Simply because VB controls are windows, VFP's aren't. That's why the MS Forms 2.0 Command Button has a setable backcolor. You're setting the window backcolor. Since it may be desirable to have a window who's backcolor is something other than the standard, such as a splash screen, that's modifiable.
>>>
>>
>>Well, that still doesn't answer the question of why a VFP command button has no control over that property. Don't waste anymore time over it, I really don't care. < BG > If I want a button to be "colorful", I use a picture.
>
>Fred, I don't mean to "preach" here, but I think it's important to understand the underlying cause of why these things are the way they are for VFP. Essentially, your looking at some the reasons that VFP has problems with ActiveX controls and other issues. I'm not saying it's right or wrong. However, if both VB and VFP used real "windows" for controls and you could change the background color on VB's and not VFP's then there'd be a real issue as to why? Here, not so much. This is part of the price we paid for VFP 3.0 for Mac.

Don't worry George, I never think you're "preaching". I value your opinion on lots of topics, especially when it comes to API and "lower level thingies" within VFP. But since you brought it up, if there is no longer any support for the Mac, why do we have to continue to "pay the price" for it's support?

>Now, let's assume that both used real windows for the controls. There'd still be a possibility for difference. For example, both VB and VFP forms are real windows, yet VFP has nearly 3 times the PEMs. The difference? The implementation.


So, do you think this will change any in VB when they get a more complete OOP model?