virtuel BOOL OnIdle ( LONG lCount );
Valeur de retour
Différente de zéro pour recevoir plus traitement des temps d'inactivité ; 0 si le temps d'inactivité n'est nécessaire.
Paramètres
lCount
Un compteur incrémenté chaque fois OnIdle est appelé lorsque la file d'attente de message de l'application est vide. Ce comte est remis à 0 chaque fois qu'un nouveau message est traité. Vous pouvez utiliser le paramètre lCount pour déterminer la durée relative de que la demande a été inactive sans traitement d'un message.
Remarques
Substituez cette fonction membre pour exécuter le traitement de temps de marche au ralenti. OnIdle est appelée dans la boucle de message par défaut lorsque la file d'attente de message de l'application est vide. Utilisez votre substitution d'appeler votre propre fond d'écran au ralenti-gestionnaire de tâches.
O&nIdle doit retourner 0 pour indiquer qu'aucun délai de traitement inactif n'est requis. Le paramètre lCount est incrémenté chaque fois OnIdle est appelée lorsque le messagenbsp ; file d'attente est vide et réinitialise à 0 chaque fois qu'un nouveau message est traité. Vous pouvez appeler vos différentes routines idle basés sur ce chef d'accusation.
Ce qui suit résume les traitement de boucle au ralenti:
OnIdle pour l'objet application et fournitures 0 comme argument lCount.OnIdleeffectue un traitement et retourne une valeur différente de zéro pour indiquer, il doit être appelée une fois de plus faire un traitement supplémentaire.OnIdle encore une fois, en incrémentant l'argument lCount.OnIdle termine le traitement de toutes ses tâches inactifs et renvoie la valeur 0. Cela raconte la boucle de message pour arrêter de réclamer OnIdle jusqu'à ce que le prochain message reçu de la file d'attente de messages, au point où l'inactivité cycle redémarre avec l'argument défini tonbsp; 0.N'effectuez pas longues tâches pendant OnIdle parce que votre application ne peut pas traiter l'entrée d'utilisateur jusqu'à ce que retourne OnIdle.
&Notenbsp ; L'implémentation par défaut de OnIdle met à jour les objets d'interface utilisateur de commande tels que les éléments de menu et les boutons de la barre d'outils, et elle effectue le nettoyage de structure de données interne. Par conséquent, si vous substituez OnIdle, vous devez appeler CWinApp::OnIdle avec le lCount dans votre version substituée. D'abord appeler toutes les classe de base traitement inactif (c'est-à-dire, jusqu'à la classe de base OnIdle renvoie la valeur 0). Si vous avez besoin effectuer les travaux avant le traitement de la classe de base complète, revoir la mise en œuvre de la classe de base pour sélectionner le bon lCount au cours de laquelle faire votre travail.
Exemple
Les deux exemples suivants montrent comment utiliser OnIdle. Le premier exemple de processus de deux tâches au ralenti à l'aide de l'argument lCount de prioriser les tâches. La première tâche est de priorité élevée, et vous devriez faire il possible. La seconde tâche est moins importante et devrait être faite seulement lorsqu'il y a une longue pause dans l'entrée d'utilisateur. Notez l'appel à la version de classe de base de OnIdle. Le deuxième exemple gère un groupe de tâches au ralenti avec des priorités différentes.
BOOL CMyApp::OnIdle(LO&NG lCount)
{
nbsp ; BOOL bMore = CWinApp::OnIdle(lCount) ;
Si (lCount == 0)
{
TRACE ("App au ralenti pour une courte période de time\n") ;
bMore = TRUE ;
}
else if (lCount == 10)
{
TRACE ("App au ralenti pendant plus de time\n") ;
bMore = TRUE ;
}
else if (lCount == 100)
{
TRACE ("App au ralenti pour un montant encore plus longtemps de time\n") ;
bMore = TRUE ;
}
else if (lCount == 1000)
{
TRACE ("App au ralenti pour tout à fait une longue période de time\n") ;
/ / bMore n'est pas défini sur TRUE, n'a plus besoin de laisser tourner au ralenti
/ / IMPORTANT : bMore n'est pas définie sur FALSE car le CWinApp::OnIdle peut
/ / ont plus de tâches inactifs pour terminer.
}
retour bMore ;
/ / retourner TRUE tant qu'il y a des tâches plus inactifs
}
Deuxième exemple
// 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 CMyApp::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 FALSE;
}
Aperçu de CWinApp |nbsp ; Membres de la classe | Graphique de la hiérarchie