Making invalid buttons no longer troublesome

// ================================================ ========================================
// Title:
// Remove invalid buttons
// Author:
// Norains
// Date:
// Wednesday 16-January-2008
// Environment:
// Vs2005 + SDK-WINCE5.0-MIPSII
// EVC + SDK-WINCE5.0-MIPSII
// ================================================ ========================================

I believe many of my friends will have such experience. There is such a button in the window, and related computation will be performed when the button is pressed. However, during the processing process, I do not intend to allow the user to click the button again, so of course the enablewindow button is called before the related operation processing starts. After the calculation is completed, enablewindow is called again to restore. there is no logic problem. Everyone will think so, isn't it? But is the result true? Let's take an example.

In our instance, there are two buttons: one is "Exit" and the other is "Disable". When the former is clicked, the program is exited, and the other is invalid. Then, sleep is used to simulate the work that takes a long time, then, restore the exit button status.

The main code is as follows (complete engineering code can be downloaded here: http://download.csdn.net/source/337027 ):

// Message process
Lresult cmainwnd: wndproc (hwnd, uint wmsg, wparam, lparam)
{
Switch (wmsg)
{
Case wm_command:
{
If (hiword (wparam) = bn_clicked & loword (wparam) = idc_btn_exit)
{
Postquitmessage (0x00 );
Return 0;
}
Else if (hiword (wparam) = bn_clicked & loword (wparam) = idc_btn_enable)
{
Onclickedbtnenable (hwnd, wmsg, wparam, lparam );
Return 0;
}
Break;
}
}
Return cwndbase: wndproc (hwnd, wmsg, wparam, lparam );
}

// Enable button Response Function
Void cmainwnd: onclickedbtnenable (hwnd, uint wmsg, wparam, lparam)
{
Testcode ();
}

// Simulate the test code
Void cmainwnd: testcode ()
{
Enablewindow (m_hbnexit, false );
Sleep (2000 );
Enablewindow (m_hbnexit, true );
}

We disabled the exit button in testcode, sleep for 2 seconds, and finally restored the exit button. Everything looks wonderful, isn't it? Let's compile and run the project!

Click the disable button to make the exit invalid. Then we click the exit button one by one. You don't need to be nervous. In fact, you can also click it multiple times as long as the exit is not restored to a valid state. okay. Stop clicking. Let's wait for exit to restore. well, two seconds later, exit is valid. ah! What's going on? Why did the program exit? Why do you click the exit button in the invalid status and then receive the exit wm_command message to exit the program after it recovers? Is the world going to be messy?

Don't be nervous. The problem is actually very simple. after we press disable, The wndproc function has been processing the disable button bn_clicked message. then we sleep for two seconds. During these two seconds, we click the exit button. At this time, the exit button will send wm_lbuttonclick, but at this time, because the bn_clicked processing function of the disable button has not returned, therefore, the system stores the exit button wm_lbuttonclick in the sending queue. after the bn_clicked handler function of the disable button is returned, the system sends wm_lbuttonclick, And the exit button is in the valid state. therefore, after receiving the wm_lbuttonclick message, the default processing function will send the exit bn_clicked message to call the exit button's processing function.

Knowing the cause makes it easy to solve the problem. Isn't it because the disable bn_clicked processing function does not return timely? So we can create a thread to let the thread do the relevant processing?

Therefore, the onclickedbtnenable function is changed as follows:
Void cmainwnd: onclickedbtnenable (hwnd, uint wmsg, wparam, lparam)
{
// Create a thread
Handle Hd = createthread (null, null, threadproc, this, 0, null );
Closehandle (HD );
}

DWORD cmainwnd: threadproc (pvoid parg)
{
Cmainwnd * pobject = (cmainwnd *) parg;
Pobject-> testcode ();
Return 0;
}

Everything is normal, isn't it?

The above method uses the thread mode. Can I not create a thread? The answer is yes, of course. The reason is that wm_lbuttonclick message processing is delayed. So we are not happy to remove the message from the Message Queue after it is effective or before it is used? I would like to express my sincere gratitude to Dr. Zhang for not having such an idea come from me!

The onclickedbtnenable function is changed as follows: void cmainwnd: onclickedbtnenable (hwnd, uint wmsg, wparam, lparam)
{
// Method 2: delete a message
Testcode ();
MSG;
While (: peekmessage (& MSG, m_hwnd, wm_lbuttondown, wm_lbuttondblclk, pm_remove ));

}

The two methods can achieve our goal. How can we choose between them? If the processing process is short and the interface does not need to respond to any button information in the processing project, method 2 is the most refreshing and appropriate. If the processing takes a long time, in this time period, the interface response needs to be processed. It is better to create a thread in method 1.