On-Idle Processing

Before multithreaded programming came along, Windows developers used on-idle processing for "background" tasks such as pagination. On-idle processing is no longer as important, but it's still useful. The application framework calls a virtual member function OnIdle of class CWinApp, and you can override this function to do background processing. OnIdle is called from the framework's message processing loop, which is actually a little more complicated than the simple GetMessage/TranslateMessage/DispatchMessage sequence you've seen. Generally, once the OnIdle function completes its work, it is not called again until the next time the application's message queue has been emptied. If you override this function, your code will be called, but it won't be called continuously unless there is a constant stream of messages. The base class OnIdle updates the toolbar buttons and status indicators, and it cleans up various temporary object pointers. It makes sense for you to override OnIdle to update the user interface. The fact that your code won't be executed when no messages are coming is not important because the user interface shouldn't be changing.

If you do override CWinApp::OnIdle, don't forget to call the base class OnIdle. Otherwise, your toolbar buttons won't be updated and temporary objects won't be deleted.

OnIdle isn't called at all if the user is working in a modal dialog or is using a menu. If you need to use background processing for modal dialogs and menus, you'll have to add a message handler function for the WM_ENTERIDLE message, but you must add it to the frame class rather than to the view class. That's because pop-up dialogs are always "owned" by the application's main frame window, not by the view window. Chapter 15 explores the relationship between the frame window and the view window.