Even better MessageBox customization can be achieved by creating an external library (ActiveX, DLL or FLL) and calling it from VFP application.
The background color, the message text font & color, button fonts and captions, not to mention other customizable parameters, can be controlled by the calling application.
* * *
C# and C++ versions of this code use the SetWindowsHookEx API function to monitor either window messages or CBT notifications within the thread. Upon detecting the WM_INITDIALOG message the code moves the recipient window -- a MessageBox dialog.
* * *
To close the dialog through virtually pressing a button, consider also sending BM_CLICK message. This message causes the button to receive the WM_LBUTTONDOWN and WM_LBUTTONUP messages, and the button"s parent window to receive a BN_CLICKED notification message.
More common way of closing the dialog is calling the EndDialog function.
* * *
The MessageBox dialog consists of several windows.
The Dialog Window is the parent window, and all others are its children.
All Button Windows and three Static Windows (the Icon Window, the Message Window and the window surrounding the buttons) have very specific window identifiers (control ids). These values appear to be undocumented though stay unchanged through the all Windows versions since Windows 95.
The Tool window (its Control ID 0x0000CAFE always makes me feel good) is an addition to the MessageBox child windows that came with the Vista.
* * *
Starting with the FVP version 8, the MESSAGEBOX() function can accept the Timeout parameter.
When the MESSAGEBOX() is called without the Timeout parameter, it runs on VFP default thread. When the Timeout parameter is passed, VFP creates a separate thread for the MESSAGEBOX().
No mater how subtle this difference may appear, it renders the GetActiveWindow useless for finding the dialog window. Calling the SetWindowsHookEx should also be performed with the consideration for the separate thread.