Erik,

>This causes a few complications when doing certain things with VFP. the most oft-heard complaint is the fact that these "painted" controls make VFP apps inoperable to most automated testing software, which uses windows handles to interact with the UI of the app being tested. Also, terminal server applications like WinFrame, LapLink, etc use handles to refresh individual parts of a remote screen at a time. Since VFP apps don't use these, the only alternative is to use the handle of the form, and refresh the entire form, which incurs a significant performance penalty.

It should be noted that ActiveX compatibility is hurt as well with controls such as the MS Coolbar.

>Arguments for painted controls include:
>Performance (this is the argument I questioned with my previous post)

Perhaps the reference is to data manipulation performance. From what I understand, VFP does a lot of internal memory management (moving it around included). If this is part of the reason that it performs as well as it does, and this had to be dropped in order to use real windows controls, then I can understand and agree with the performance argument.

>PEMs. I see where this argument is coming from, but I question it as well. VB textboxes have about 25 events, VFP textboxes expose about 29. Not that big of a difference. Anyway, my hacker nature tells me that the VFP team could find a way to expose all of the events we have now even with real controls.

I have a hard time believing this as I mentioned in my post to Craig. Given that VFP forms have almost double the PEMs of VB, they're "real" windows, I just can't see it.

>All in all, I think that real controls would be nice in some cases, but for the most part, I don't really care. There are a lot of things I would like to see implemented before they spend all the time it would take to make a change like this.