About wm_nchittest messages

I used the WM_NCHITTEST message to move a form without a title bar, which is probably as follows:

In general, we drag the title bar of the dialog window to move the window, but sometimes we want to move the window by dragging the mouse over the client area.

An easy-to-think scenario is to handle mouse messages Wm_lbuttondown and wm_lbuttonup. In the OnLButtonUp function to calculate the change in the mouse position, call MoveWindow to implement the window movement.

Note that when you drag the title bar to move the window, a rectangular box appears, prompting the current position of the window to move. When the left mouse button is released, the window moves to the position of the rectangle box. We do not have this capability in our implementation scenario.

To implement this function, we have to draw these rectangles ourselves.

In fact, we don't have to do it ourselves, because Windows has done it for us.

Imagine if I could cheat windows and tell it now that the mouse is dragging the title bar instead of the client area, then Windows will do the work.

To deceive windows is not as difficult as imagined, even very simple.

We use a message: Wm_nchittest.

The MSDN explanation for it is:

The wm_nchittest message is sent to a window when the cursor moves, or if a mouse button is pressed or released . If the mouse is not captured, the message was sent to the window beneath the cursor. Otherwise, the message is sent to the window, which has captured the mouse.

The message is sent when the mouse moves or the mouse button is pressed.

What does windows do with this message? "HITTEST" is the meaning of "hit test", the WM_NCHITTEST message is used to get the position of the mouse's current hit.

WM_NCHITTEST's message response function determines which part of the window the mouse is hitting according to the current coordinates of the mouse, and the return value of the message response function indicates the location, for example, it may return htcaption, or htclient, and so on. (There are many return values, please refer to MSDN).

For the sake of understanding, let me first describe the response process of Windows to mouse button presses:

1. Determines which window the mouse button is clicked on. Windows uses the table to record the area coordinates of each window on the current screen, and when the mouse driver notifies windows that the mouse button is pressed, Windows determines which window it clicks based on the coordinates of the mouse.

2. Determines which part of the window the mouse button is clicked on. Windows sends a WM_NCHITTEST message to the mouse-clicked window to ask what part of the window the mouse button clicked on. (The return value of the WM_NCHITTEST message response function notifies Windows). Generally speaking, wm_nchittest messages are handled by the system, and the user generally does not take the initiative to deal with it (that is, the WM_NCHITTEST message response function usually takes the Windows default handler function).

3. According to the mouse button click on the part of the window to send the corresponding message. For example, if the return value of the WM_NCHITTEST message response function is htclient, indicating that the mouse is clicked on the client area, Windows sends a WM_LBUTTONDOWN message to the window if wm_ The return value of Nchittest's message response function is not htclient (possibly Htcaption, htclose, Htmaxbutton, etc.), which is the non-client area of the mouse click, and Windows sends a WM_NCLBUTTONDOWN message to the window.

We need to discuss it in detail: if the return value of Wm_nchittest's message response function is htcaption, that indicates that the mouse clicked on the title bar, and then what about Windows processing?

As mentioned above, next, Windows sends a WM_NCLBUTTONDOWN message to the window.

MSDN's description of the Wm_nclbuttondown message is as follows:

Wm_nclbuttondown

Nhittest = (INT) WParam; Hit-test value

pts = makepoints (LParam); Position of cursor

Wm_nclbuttondown's wparam indicates the window part of the mouse click, lparam indicates the current mouse coordinates.

If the application does not respond to the message, it is handled by the system by default.

What does the system default handle? System Discovery wparam indicates that the mouse click is the title bar, it will identify the current window is in a "drag state" (Windows internal records the status information of each window). Since the "drag state" is identified, your mouse movement condition is completely tracked by Windows until the mouse button is released from this moment. It moves the window "synchronously", depending on the movement of the mouse.

Note that during this process, the window does not receive the Wm_ncmousemove message because the window and mouse are "synchronized" and your mouse is still relative to the window.

But the problem also appeared, I would like to right-click on this form to pop up a menu, when I finished msg_wm_rbuttondown this message, found that the form does not receive this message, the implementation of the WM_NCHITTEST message can be removed, see a reason is:

Because you processed the mouse message in the wm_nchittest, positioning him as a htcaption, that is, the mouse in the title bar, and the title bar belongs to the non-client area (NC);
Event messages for non-client areas begin with WM_NC. In other words, when your wm_nchittest returns to Htcaption, you can use WM_LBUTTONUP to process the message, you can only use Wm_nclbuttonup to handle.

Workaround:

Handles Wm_nchittest and wm_ncrbuttonup simultaneously, without processing wm_rbuttonup

About wm_nchittest messages