CWinApp::OnIdle
유휴 시간 처리를 수행 하려면이 멤버 함수를 재정의 합니다.
virtual BOOL OnIdle(
LONG lCount
);
매개 변수
- lCount
카운터가 증가 될 때마다 OnIdle 응용 프로그램의 메시지 큐가 비어 있을 때 호출 됩니다.이 수는 새 메시지가 처리 될 때마다 0으로 재설정 됩니다.사용할 수는 lCount 매개 변수가 상대 응용 했습니다 유휴 메시지를 처리 하지 않고 시간을 확인 합니다.
반환 값
0이 아닌 보다 유휴 처리 시간을 받을 수 있습니다. 유휴 시간이 필요한 경우 0입니다.
설명
OnIdle응용 프로그램의 메시지 큐가 비어 있을 때 기본 메시지 루프에서 호출 됩니다.자신의 배경 작업 유휴 처리기를 호출 하 여 재정의 사용 합니다.
OnIdle유휴 처리 시간이 필요 함을 나타내기 위해 0을 반환 해야 합니다.lCount 매개 변수는 때마다 증가 됩니다 OnIdle 메시지 대기열이 비어 있고 새 메시지가 처리 될 때마다 0으로 다시 설정 하는 경우 호출 됩니다.이 수에 따른 다른 유휴 루틴을 호출할 수 있습니다.
유휴 루프 처리를 요약 하면 다음과 같습니다.
Mfc 라이브러리에서 메시지 루프 메시지 큐를 검사 하 고 더 보류 중인 메시지를 발견 하는 경우 호출 OnIdle 0으로 공급 및 응용 프로그램 개체는 lCount 인수.
OnIdle일부 처리를 수행 하 고 0이 아닌 값이 표시 되어야 호출 다시 할 반환 처리가.
메시지 루프는 메시지 큐를 다시 검사합니다.보류 중인 메시지가 호출 OnIdle 다시 증가 lCount 인수.
결국, OnIdle 모든 유휴 작업 처리를 완료 하 고 0을 반환 합니다.이 메시지 루프를 호출을 중지 알려 OnIdle 메시지 대기열에서 다음 메시지를 받을 때까지 유휴 사이클 인수 0으로 설정 하 여 함께 다시.
긴 작업 동안 수행 하지 않습니다 OnIdle 사용자 입력 될 때까지 응용 프로그램에서 처리할 수 있기 때문에 OnIdle 반환 합니다.
[!참고]
기본 구현 된 OnIdle 업데이트 명령을 메뉴 항목과 도구 모음 단추와 같은 사용자 인터페이스 개체와 내부 데이터 구조를 정리를 수행 합니다.따라서 재정의할 경우 OnIdle를 호출 해야 CWinApp::OnIdle 에 lCount 재정의 된 버전의.먼저 유휴 처리 모든 기본 클래스를 호출 (즉, 기본 클래스까지 OnIdle 0 반환).기본 클래스 처리가 완료 되기 전에 작업을 수행 하려면 적절 한 선택에 기본 클래스 구현을 검토 lCount 작업을 수행 하는 동안.
원하지 않는 경우 OnIdle 메시지 큐에서 메시지를 검색할 때마다 호출을 재정의할 수 있는 CWinThreadIsIdleMessage.매우 짧은 타이머를 설정 응용 프로그램 또는 시스템에 보내는 경우는 WM_SYSTIMER 다음 메시지 OnIdle 반복적으로 호출 되 고 성능이 저하 됩니다.
예제
다음 두 예제에서는 사용 방법을 보여 줍니다. OnIdle.첫 번째 예제를 사용 하 여 두 유휴 작업 처리는 lCount 인수를 사용 하 여 작업의 우선 순위입니다.제일 높은 우선 순위 이며 가능한 경우 수행 해야 합니다.두 번째 작업 덜 중요 하며 사용자 입력에 오래 지연 된 경우에 수행 해야 합니다.참고 기본 클래스 버전을 호출 OnIdle.두 번째 예제에서는 서로 다른 우선 순위를 유휴 작업 그룹을 관리합니다.
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
}
두 번째 예제
// 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;
}
요구 사항
헤더: afxwin.h