CWinApp::OnIdle
Überschreiben Sie diese Memberfunktion, um das Leerlaufverarbeiten auszuführen.
virtual BOOL OnIdle(
LONG lCount
);
Parameter
- lCount
Ein Indikator jedes Mal inkrementiert, wenn OnIdle aufgerufen wird, wenn die Meldungswarteschlange der Anwendung leer ist. Diese Anzahl wird auf 0 zurückgesetzt, wenn eine neue Nachricht verarbeitet wird. Sie können den lCount-Parameter verwenden, um die relative Zeitspanne zu bestimmen, die die Anwendung im Leerlauf war, ohne eine Nachricht zu verarbeiten.
Rückgabewert
Wert ungleich 0, um mehr Leerlaufverarbeitungsverarbeitungszeit zu empfangen, 0 die Leerlaufzeit nicht mehr benötigt wird.
Hinweise
OnIdle wird in der Standardeinstellung Meldungsschleife aufgerufen, wenn die Meldungswarteschlange der Anwendung leer ist. Verwenden Sie die Überschreibung, eigene Hintergrund LeerlaufHandler Aufgaben aufzurufen.
OnIdle sollte 0 zurückgeben, um anzugeben, dass keine Leerlaufverarbeitungsverarbeitungszeit erforderlich ist. Der lCount-Parameter wird jedes Mal inkrementiert, wenn OnIdle aufgerufen wird, wenn die Meldungswarteschlange leer ist und setzt auf 0 jedes Mal eine neue Nachricht verarbeitet wird. Sie können die verschiedenen Routinen im Leerlauf auf Grundlage dieser Anzahl aufrufen.
Im Folgenden sind Leerlaufschleifen-Verarbeitung zusammengefasst:
Wenn die Meldungsschleife in Microsoft Foundation Class-Bibliothek die Meldungswarteschlange überprüft und keine ausstehenden Nachrichten ermittelt, ruft sie OnIdle für das Anwendungsobjekt auf und gibt 0 als das lCount-Argument an.
OnIdle führt bestimmte Verarbeitungsschritte aus und gibt einen Wert ungleich 0, um es anzugeben sollten erneut aufgerufen werden, um weiteren Verarbeitung durchzuführen.
Die Nachrichtenschleife überprüft die Meldungswarteschlange erneut. Wenn keine Meldungen ausstehen, ruft sie OnIdle erneut auf und erhöht das lCount-Argument.
Schließlich beendet OnIdle, alle Ruheschleifen zu verarbeiten und gibt 0 zurück. Dadurch wird die Meldungsschleife mit, um OnIdle aufzurufen, anzuhalten, bis die folgende Meldung aus der Meldungswarteschlange empfangen wird, an der Schleife im Leerlauf mit dem Argument neu gestartet wird, das auf 0 festgelegt ist.
Führen Sie langwierige Aufgaben nicht während OnIdle aus, da die Anwendung Benutzereingaben nicht verarbeiten kann, bis OnIdle zurückgibt.
Hinweis
Die Standardimplementierung von OnIdle Updates beherrschen Benutzeroberflächen-Objekte wie Menüelemente und Symbolleisten-Schaltflächen, und sie werden interne Datenstrukturbereinigung aus.Wenn Sie OnIdle überschreiben, müssen Sie CWinApp::OnIdle mit lCount in der überschriebenen Version aufrufen.Der erste Aufruf alle Basisklassenleerlaufverarbeitung (das heißt, bis die Basisklasse OnIdle gibt 0 zurück).Wenn Sie Aufgaben ausführen müssen, bevor das Basisklassenverarbeiten abgeschlossen ist, überprüfen Sie die Basisklassenimplementierung, um richtige lCount auszuwählen, während der die Arbeit ausführt.
Wenn Sie OnIdle nicht aufgerufen werden soll, wenn eine Meldung aus der Meldungswarteschlange abgerufen wird, können Sie CWinThreadIsIdleMessage überschreiben. Wenn eine Anwendung einen sehr Kurzarbeiter festgelegt hat oder wenn das System die WM_SYSTIMER Meldung sendet, wird OnIdle wiederholt aufgerufen und die Leistung beeinträchtigt.
Beispiel
In den beiden folgenden Beispielen wird veranschaulicht, wie OnIdle verwendet. Im ersten Beispiel verarbeitet zwei Ruheschleifen mithilfe des lCount-Arguments, die Aufgaben priorisieren. Die erste Aufgabe ist mit hoher Priorität, und Sie sollten sie dazu, wann immer möglich. Die zweite Aufgabe ist weniger wichtig und sollte nur möglich, wenn eine lange angehalten in der Benutzereingabe gibt. Beachten Sie den Aufruf in die Basisklassenversion von OnIdle. Das zweite Beispiel verwaltet eine Gruppe Ruheschleifen mit unterschiedlichen Prioritäten.
BOOL CMyApp::OnIdle(LONG lCount)
{
BOOL bMore = CWinApp::OnIdle(lCount);
if (lCount == 0)
{
TRACE(_T("App idle for short period of time\n"));
bMore = TRUE;
}
else if (lCount == 10)
{
TRACE(_T("App idle for longer amount of time\n"));
bMore = TRUE;
}
else if (lCount == 100)
{
TRACE(_T("App idle for even longer amount of time\n"));
bMore = TRUE;
}
else if (lCount == 1000)
{
TRACE(_T("App idle for quite a long period of time\n"));
// bMore is not set to TRUE, no longer need idle
// IMPORTANT: bMore is not set to FALSE since CWinApp::OnIdle may
// have more idle tasks to complete.
}
return bMore;
// return TRUE as long as there are any more idle tasks
}
Zweites Beispiel
// In this example, four idle loop tasks are given various
// opportunities to run:
// Task1 is always given a chance to run during idle time, provided
// that no message has queued up while the framework was processing
// its own idle loop tasks (at lCount levels 0 and 1).
// Task2 is given a chance to run only if Task1 has already run,
// provided that no message has queued up while Task1 was running.
// Task3 and Task4 are given a chance to run only if both Task1 and
// Task2 have already run, and no message has queued up in the mean
// time. If Task3 gets its chance to run, then Task4 always gets
// a chance to run immediately after Task3.
BOOL CMyWinApp::OnIdle(LONG lCount)
{
// In this example, as in most applications, you should let the
// base class CWinApp::OnIdle complete its processing before you
// attempt any additional idle loop processing.
if (CWinApp::OnIdle(lCount))
return TRUE;
// The base class CWinApp::OnIdle reserves the lCount values 0
// and 1 for the framework's own idle processing. If you wish to
// share idle processing time at a peer level with the framework,
// then replace the above if-statement with a straight call to
// CWinApp::OnIdle; and then add a case statement for lCount value
// 0 and/or 1. Study the base class implementation first to
// understand how your idle loop tasks will compete with the
// framework's idle loop processing.
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; // cycle through the idle loop tasks again
}
return TRUE;
}
Anforderungen
Header: afxwin.h