How to solve the problem of "sluggish" during business processing?
Zhzxl
2004-12-08
statement of problem:
When a business is triggered on a Windows window (for example: dialog), it is often encountered: the entire window instantly becomes sluggish, unable to drag, switch, and refresh; even if you create a non-modal window to reflect business The process of dealing with it is not good. Below is the situation that appears in a project.
Processing the business:
After clicking the "Summary" button:
It can be seen from the above figure that the interface cannot be refreshed in the process of business processing. What is the cause of this situation?
The reason for the problem:
The cause of the above problem is: business processing, interface response refresh, etc. is placed in the same thread. Therefore, when the running time of the entire thread is used to deal with the service, the interface naturally cannot respond and refresh, and there is a "sluggish" problem. Of course, in most cases, the business can be treated in an instant, and the user does not feel the order of the various messages, and it is not all done at the same time.
Here, I don't want to discuss the message processing mechanism of the operating system, but give two solutions for the above questions, and limit: only one business process is allowed in any time program process. Note: The code that appears in the program uses the form of the class VC.
Solution:
First, for the problem of the problem, the author gives the simplified mode of the interface program processing:
Where: (Note: Interface parameters are not given)
Class iForm {
Virtual bool getsetting () = 0; // Get settings
}
Class iuicontrol {
Virtual void runtask () = 0; // triggers business
}
Virtual ientity {
Virtual Bool Process () = 0; // Business Processing
}
The sequence diagram is as follows:
Scenario 1: Display call message API
The occasion of this scheme is that the process of service can be divided into a plurality of minute sub-processing processes, while the process of the child is only tiny. Assume that the sub-process processing function is given by the IENTITY interface, described as: miniprocess.
Then iuicontrol :: Runtask can be changed to:
Void iuicontrol :: runtask ()
{
IF (iForm :: getSetting ())
{
In the CWAITCURSOR WAIT; / / During processing, user operation is prevented, but does not prevent system messages
MSG Message;
While (Is it end?)
{
IAentity :: miniprocess ();
// Receive and distribute messages
IF (: PeekMessage (& Message, NULL, 0, 0, PM_REMOVE)) {
:: TranslateMessage (& Message);
:: DispatchMessage (& Message);
}
}
}
}
As can be seen from the implementation code, this approach does not increase the number of threads, but in the process of service processing, the message receives and distributed functions, and the intermittent response message.
Solution 2: Add business processing thread
This scenario is useful in the operation of the business process, or the child process itself needs a long time spending. A feedback window is added to the program so that some feedback information can be seen during business processing. This window can be implemented with non-modular dialogs and is created in the initialization function of the interface.
The improved class diagram is as follows: The sequence diagram of the improvement is as follows:
Add private thread functions in interface control:
Static Bool WinAPI ThreadProc (lpvoid lpparam)
{
IEentity * LpenTies = (iAntity *) LPPARAM;
Return LPPAR_> Process ();
}
Change the implementation of iuicontrol :: Runtask to:
Void iuicontrol :: runtask ()
{
IF (iForm :: getSetting ())
{
DWORD ID;
AFXBEGINTHREAD (ThreadProc, (LPVOID) business class pointer);
}
}
As can be seen from the implementation code, the business office is responsible for a separate thread, so there is no blocking message on the interface, thereby solving the problem of "sluggish".
Conclusion:
This paper proposes two programs to solve the problem of "dullness" during business processing. The solution is simple and clear, easy to use, and also is also suitable for transformation of existing code. However, the program only provides a framework for solving the problem, and it needs to improve and supplement when encountering specific problems. The problem of re-entry is required when using the scheme to avoid inexplicably errors. The program does not consider the situation of multi-service processing concurrency, leaving the user to handle itself.
