Re: UI Freeze Problem
On 10 Aug 2006 22:33:15 -0700, "rahulthathoo" <rahul.thathoo@gmail.com>
wrote:
My problem is that the cpu usage becomes 100% - this is because i need
to refresh the dialog after a sleep of 10 miliseconds. but the problem
is that the sleep makes the UI freeze. I thought a workaround would be
using threads. but even after using threads and events the problem
persists - the UI still freezes. Please tell me what is going wrong
here. Here is the code listing:
void Cmalt6Dlg::OnPaint()
{
....
....
......
HANDLE hEvent;
HANDLE hThread;
DWORD dwThreadID;
DWORD dwStatus;
hEvent = CreateEvent( NULL,
FALSE,
FALSE,
NULL
);
if( hEvent == NULL ) //oops!
{
printf( "CreateEvent() failed!\n" );
return;
}
hThread = CreateThread( NULL,
You should use AfxBeginThread in MFC programs. For more on that and
MFC-specific issues, see:
http://members.cox.net/doug_web/threads.htm
NULL,
(LPTHREAD_START_ROUTINE)ThreadFunction,
(LPVOID)hEvent,
NULL,
&dwThreadID
);
if( hThread == NULL ) //oops!
{
printf( "CreateThread() failed!\n" );
CloseHandle( hEvent );
return;
}
hBmp = (HBITMAP)::LoadImage(
NULL,
szFilename3,
IMAGE_BITMAP,
0,
0,
LR_LOADFROMFILE|LR_CREATEDIBSECTION
);
CBitmap* pOldBmp1;
CBitmap* pOldBmp2;
CPen *pOldPen, blackPen;
blackPen.CreatePen(PS_SOLID,1,RGB(0,0,0));
CDC* pDC = GetDC();
int count = 0;
while(TRUE)
{
dwStatus = WaitForSingleObject(hEvent,0);
This is a busy loop that will consume 100% of the CPU while hEvent is
unsignaled.
if(dwStatus == WAIT_OBJECT_0 )
{
.....
.....
}
}
}//close OnPaint()
DWORD ThreadFunction( LPVOID lpArg )
{
HANDLE hEvent = (HANDLE)lpArg;
while(TRUE)
{
Sleep( 5 );
SetEvent( hEvent ); //set the event state to signalled
}
return 0L;
}
To remain responsive, your UI thread has to process messages while it's
waiting on the worker. If you want to continue to use events for
communication, you'll need to write your own MsgWaitForMultipleObjects
loop; the link I gave above talks about this. An alternative would be for
your UI thread to drop back into its message loop and the worker to
PostMessage to a window belonging to the UI thread. That said, creating a
thread in response to WM_PAINT is a bad idea, and you should avoid entering
a message loop while in WM_PAINT. I don't understand what you're trying to
do, but to delay drawing for 10 msec inside WM_PAINT, you might maintain a
pool of threads that receive "10 msec wait" requests and PostMessage a
custom message when the timer expires. You might also be able to avoid
threads and use SetTimer. Finally, you'd have to distinguish between these
"10 msec wait" WM_PAINTs and the WM_PAINTs you actually want to draw in;
maintaining a boolean flag in your window class should help you do this.
--
Doug Harrison
Visual C++ MVP