Hi Kevin,

>So how bout this. Is it possible to open a standard "Windows" hWnd window outside of FoxPro with a FoxPro command? That way I could send all status info. to that window.

Unless you mean running something like a VB or VC++ program that would serve as an intermediary, I don't think so. Window creation via the API is beyond the capacity of the current version of VFP. You'd have to indicate the address of a callback function to process the messages.

>That's kinda strange that FoxPro has hWnd funtions yet the windows does not act the same as a standard hWnd.
>

As I understand it, the current design was implemented to maintain cross platform ability with the Mac. VFP only accesses the standard windows functions, and keeps its own references to the individual windows (via what's referred to as a whandle) as well as the standard hWnd.

Since Mac compatibility has been more or less dropped, we may see VFP be adapted to standard windows behavior and controls. While this would be a major re-write, when (and if) 64 bit VFP comes out that would be the time to look for it.

Before anyone jumps me for the above statement, they should consider the following. There will be a 64 bit version of Windows. The specifications are currently available. In order for 32 bit applications to run under it, they would, have to do via a thunking layer as 16 bit apps currently have to do to run under Win 32. If VFP is to remain a viable product (don't go there folks!), it only stands to reason that it will eventually be ported to 64 bits, as will other Windows products (both applications and development tools). However, such a port will require more than a simple re-compile. There will be new structures and functions, according to the specs I've seen, that VFP will need to access. For example, VFP 3.0 represented a major shift in the development paradigm. One of the reasons it did, I believe, was the fact that it was the first FoxPro product that could generate 32 bit applications. The port from 16 to 32 afforded MS the opportunity to implement the shift in methodology. Similarly, the port from 32 to 64 bits will again provide MS the opportunity to implement significant changes. Whether or not it will occur is another matter.

The above is simply IMHO, I could be wrong...