>>>Not in VFP, they aren't. I don't think this is any different in VFP 7. The only enhancement I've heard is that the hWnd property is being added to forms. If it were differnt in VFP 7, that would have involved a major rewrite.
>>
>>Larry,
>>
>>You're right. In VFP 7.0, the native VFP controls (with the exceptions of course of form and toolbar) aren't real "windows", the way they are in other languages. In short, no hWnd, no WndProc, etc. Anyone with the complete VS can verify this by dropping any VFP control on a form, running it, then running the Spy++ utility. You'll see the form, but nothing on it. Then drop something like the MS Calendar Control 8.0 on the form and refresh Spy++. Not only will the Calendar control show up, but the two combos as well.
>
>Oh to be not right in this instance. :-) Think of the possibilities.

For awhile I speculated that we might get them in the 64 bit version when it arrives. However, I've come to the conclusion that this is one of those things that'll never happen. In some respects, it may not be a bad thing. One area that might be hurt is form refreshes. Assume the following:

You set LockScreen to .T., issue ThisForm.Refresh to update all the controls, then set LockScreen back to .F. In this scenario, VFP issues a LockWindowUpdate() on the form, updates the controls, then calls LockWindowUpdate again to release the lock.

If each of the controls were windows, you couldn't do this. In fact, LockScreen might only be a property for backward compatibility. Windows can only lock one window at a time. This means that each control would have to individually be locked and unlock. Certainly, one, with judicious use of ThisForm.Refresh, might not see much of a performance hit, but there would almost certainly be one.