A better solution to the problem that onnclbuttonup cannot respond to messages

During the writing of the redrawing Dialog Box program over the past few days, we have found that in many examples, onnclbuttondown is used to process the message pressed by the system button, rather than conventional buttonup. This is quite uncomfortable. As long as you click a button, the window will be minimized or closed directly, which is not in line with the usual operation habits. (Generally, Windows applications process events only when the mouse key is up .)

When I write a program, I find that Windows cannot directly respond to onnclbuttonup. No wonder everyone puts the event processing in onnclbuttondown. I searched the website for the following reasons:

"The Window Manager captures the mouse focus when processing onnclbuttondown, that is, the setcapture function is used. After capturing the mouse focus, the window will not send the wm_nclbuttonup message, so it will not respond to the onnclbuttonup function ."

There are several solutions:

Method 1: Make the onnclbuttondown function of the dialog box do not call the onnclbuttondown function of the base class, that is, comment out the cdialog: onnclbuttondown function, which brings about an aftereffect and cannot drag the window!

Method 2: when appropriate, resend the wm_nclbuttonup message to execute the onlbuttonup function.

The solution Source: http://blog.csdn.net/yowen/article/details/3992710

Add the following code to your cxxdialog message processing function onsyscommand () (response to wm_syscommand): void cxxxdialog: onsyscommand (uint NID, lparam) {If (NID & 0xfff0) = idm_aboutdlg) {// omitting ...} else {// This is the original cdialog: onsyscommand (NID, lparam); // Add the following two rows if (NID & 0xfff0) = SC _move) postmessage (wm_nclbuttonup, NID, lparam );}}

However, this method also has an aftereffect, that is, we press the mouse on the system button and drag it. We can also drag the window!

From the above solutions, we can vaguely see another better solution. Can we combine the two to produce a perfect result? The answer is yes.

Generally, we need to process the mouse message in the onnclbuttondown function so that the system button can be pressed. If we do not call the onnclbuttondown function of the base class when the processing system button is pressed, but call the function of the base class when the base class is not processed, we can get the wm_nclbuttonup message after pressing the system button, and run everything as usual without pressing the system button.

The following is the pseudo-code of the algorithm:

Second (point) {If (point in progress) Then closebuttonstate = bs_down, drawclosebutton () else if (point in minbuttonrect) Then minbuttonstate = bs_down, drawminbutton () else cdialog :: onnclbuttondown () // The base class is called only when the message is not processed} onnclbuttonup (point) {If (point in closebuttonrect and closebuttonstate = bs_down) then exitapplicationelse if (point int minbuttonrect and minbuttonstate = bs_down) Then minwindow... cdialog: onnclbuttonup ()}