>>and VB uses real controls. I know that the decision to use painted controls was based on performance....
>
>Splain Lucy, splain... :)

Form controls in Visual Basic have a hWnd property that is their Windows handle. VFP controls are not real Windows controls and so don't have windows handles, IOW, they are only painted on the screen to look like real controls. From what I understand, this was done originally because the Fox team figured they could make their UI faster by bypassing the Windows way of doing things, and building their controls themselves. (And, as George pointed out, poissibly for MAC compatibility: to help cross platform VFP runtimes to share a larger codebase).

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.

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

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.


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.