Virtual BOOL OnIdle (LONG lCount);
Return value: Returns a value other than 0 if you want to receive more idle processing time, or 0 if no more idle time is required.
Parameters:
| LCount |
This parameter is a count value that increases by 1 when the OnIdle function is called when the application's message queue is empty. Whenever a new message is processed, the count value is reset to 0. You can use the Lcount parameter to determine the relative length of idle time when the application does not process messages. |
Description
This member function is overloaded if you want to perform idle-time processing. When the application's message queue is empty, the OnIdle is called in the default message loop. You can use the overloaded function to invoke your own background idle processing task.
OnIdle should return 0 to indicate that no additional idle processing time is required. When Message Queuing is empty, the Lcount parameter is incremented each time the OnIdle is called, and a new message lcount is reset to 0 per processing. You can invoke different idle processing routines based on this count value.
The following summarizes the idle loop processing:
| 1. |
If the message loop in the Microsoft Base Class library checks the message queue and discovers that there are no unhandled messages, it calls the OnIdle function for the Application object and sets the Lcount parameter to 0. |
| 2. |
OnIdle performs some processing and then returns a non-0 value indicating that it also needs to be called for further processing. |
| 3. |
The message loop checks the message queue again. If there are no unhandled messages, call OnIdle again to increase the lcount parameter. |
| 4. |
Finally, OnIdle ends all the idle tasks and returns 0. This tells the message loop to stop calling OnIdle until the next message is received in the message queue, at which point the idle loop restarts, and the parameter is set to 0. |
Because the application can handle user input only after OnIdle returns, there should be no longer tasks in OnIdle.
Attention:
The default implementation of OnIdle updates the command user interface objects, such as menu items and toolbars, and also implements the cleanup of internal data structures. Therefore, if you overload the OnIdle, you must call CWinApp::OnIdle with the Lcount value used in the overloaded version. The idle processing of all base classes is called first (that is, until OnIdle of the base class returns 0). If you need to do some work before the base class finishes processing, you should review the implementation of the base class to select an appropriate lcount value during your own work.
Example:
The following two examples illustrate the use of onidle.
The first example deals with two idle tasks, using the Lcount parameter to prioritize these tasks. The first task has a higher priority, and you should perform this task once it is possible. The second task is not very important and should only be performed if the user enters an interval that has a longer period of time. Note the call to the base class for OnIdle. The second example manages a set of idle tasks with different priorities.
BOOL Cmyapp::onidle (LONG lCount)
{
BOOL bmore = CWinApp::OnIdle (LCount);
if (LCount = = 0)
{
TRACE ("App idle for short period of time\n");
Bmore = TRUE;
}
else if (LCount = = 10)
{
TRACE ("App idle for longer amount of time\n");
Bmore = TRUE;
}
else if (LCount = = 100)
{
TRACE ("App idle for even longer amount of time\n");
Bmore = TRUE;
}
else if (LCount = = 1000)
{
TRACE ("App idle for quite a long period of time\n");
Bmore is not set to true and does not need to be idle
Important: Bmore is not set to FALSE because CWinApp::OnIdle may have other idle tasks to complete.
}
Return bmore;//returns true as long as there are other idle tasks
}
A second example:
In this example, there are four idle loop tasks, which are given
Different priorities, different chances of running:
Task1 always runs when idle, requiring no message waiting while the framework handles its own idle loop task. (Lcount is 0 or 1)
Task2 runs only when Task1 and runtime require that no messages are waiting while the TASK1 is running.
Task3 and Task4 run only when Task1 and Task2 are running,
And no messages are waiting during this time. If TASK3 can run,
The TASK4 always runs immediately after TASK3.
BOOL Cmyapp::onidle (LONG lCount)
{
In this example, like most applications, you should let the base class
The cwinapp::onidle in you try to make any additional idle loops
Process before completing its processing.
if (CWinApp::OnIdle (LCount)) return TRUE;
The cwinapp::onidle of the base class are reserved for lcount 0 and 1 for the frame's own
Idle processing is used. If you want to share idle processing equally with the framework,
Time, you should replace the above if statement and call CWinApp::OnIdle directly,
Then add a case statement for the value 0 and/or 1 of the lcount. The first step should be to develop
The implementation of the base class to understand how your idle loop task will relate to the framework's
The idle loop handles the competition.
Switch (lCount)
{
Case 2:
Task1 ();
return TRUE; Next time, give Task2 a chance.
Case 3:
Task2 ();
return TRUE; Next time, give Task3 and Task4 a chance.
Case 4:
Task3 ();
Task4 ();
return FALSE; Back to the idle loop task again
}
return FALSE;
}
How to use CWinApp::OnIdle
