If you've been keeping count, you know that we've covered 20 of the 21 mouse messages. The last message is WM_NCHITTEST, which stands for ”nonclient hit test.“ This message precedes all other client-area and nonclient-area mouse messages. The lParam parameter contains the x and y screen coordinates of the mouse position. The wParam parameter is not used.
Windows applications usually pass this message to DefWindowProc. Windows then uses the WM_NCHITTEST message to generate all other mouse messages based on the position of the mouse. For nonclient-area mouse messages, the value returned from DefWindowProc when processing WM_NCHITTEST becomes the wParam parameter in the mouse message. This value can be any of the wParam values that accompany the nonclient-area mouse messages plus the following:
| HTCLIENT | Client area |
| HTNOWHERE | Not on any window |
| HTTRANSPARENT | A window covered by another window |
| HTERROR | Causes DefWindowProc to produce a beep |
If DefWindowProc returns HTCLIENT after it processes a WM_NCHITTEST message, then Windows converts the screen coordinates to client-area coordinates and generates a client-area mouse message.
If you remember how we disabled all system keyboard functions by trapping the WM_SYSKEYDOWN message, you may wonder if you can do something similar by trapping mouse messages. Sure. If you include the lines:
case WM_NCHITTEST :
return (long) HTNOWHERE ;
in your window procedure, you will effectively disable all client-area and nonclient-area mouse messages to your window. The mouse buttons will simply not work while the mouse is anywhere within your window, including the system menu box and size box.