>>I'll admit that I was wrong regarding the WHANDLE issue. I was relying on the documentation that you, quite correctly, pointed out was incorrect.
>>
>
>Ok
>
>>However, why is this necessary? VFP windows have a hwnd (abstract datatype, BTW) property. Why should we rely on a mechanism that was originally developed for Win16? It's a simple API call to retrieve the correct value, or, better, design for easy retrieval.
>
>I Agree.
>But inner VFP uses still the WHANDLE, and the APILC (whose development is died !!!),
>uses only WHANDLE for Window Manipulation.
>Then, with SYS(232X) a developer can to integrate calls APILC with the use of BINDEVENT(hWnd...).
>
Fabio,

If I had to guess, I'd say this was a "backward compatibility" issue.

There are two sides to this story.

One side is, that because, VFP handles windows type controls internally (IOW, where in other development environments somthing like a command button is actually a window, in VFP it isn't). AFAIK, VFP uses the whandle for internal purposes, like refreshing (or re-painting) the window. In fact, all of Windows messages (even in an SDI app) are processed through the VFP main window (_VFP.hWnd).

OTOH, if VFP's controls where actually standard (MCF) controls, there'd be a noticable slowdown in things like instantiating a form. Further, we would not be able to have surrogate controls on page frames.