"Aditya" <adityabo...@gmail.com> ha scritto nel messaggionews:e77e8622-9295-45c2-b0ae-1b8d3c9ded2e@i12g2000prf.googlegroups.com...
but my
question is if i block
it and during that period did some UI operation from other
threads..why UI get hangs...is there any reason special reason like
need
to process the message immediately
When your app starts, Windows calls a function whose name is "WinMain".
If you want to write a WinMain implementation, you will do some
initialization like creating a window, etc.
And you would also code what is called a "message pump". That is a loop
something like this:
<code>
...
//
// Message-pump (inside WinMain)
//
BOOL bRet;
while( (bRet = GetMessage( &msg, hWnd, 0, 0 )) != 0)
{
if (bRet == -1)
{
// handle the error and possibly exit
}
else
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
}
// App terminates - return to Windows
return msg.wParam;
</code>
The message pump takes messages from the message queue (if any) and
dispatches them to the window procedure.
You specify a pointer to a function (which is the window procedure) when
registering window class.
The window procedure typically implements a very big switch statement, to
process the messages Windows sends to your window, e.g.
<code>
//
// Window procedure: process messages sent to our window
//
LRESULT CALLBACK WindowProc(HWND hWnd, UINT iMsg, WPARAM wParam, LPARAM
lParam)
{
...
switch (iMsg)
{
case WM_CREATE:
....
case WM_PAINT:
...
case WM_SETFOCUS:
...
case WM_SIZE:
....
case WM_DESTROY:
...
...etc. ...
}
// Default processing by Windows
return DefWindowProc(hWnd,iMsg,wParam,lParam);
}
</code>
MFC hides all that behind the scene.
But if you write Win32 applications (without the help of MFC), you have to
write that kind of code and understand all that.
If you have a lengthy operation, you are not returning to Windows soon, so
the message-loop (in WinMain) is waiting for you to finish process your
message.
Messages like WM_PAINT (important to e.g. redraw the GUI), WM_SIZE, etc. are
not processed, because you are busy in your lengthy operation, and you don't
return soon to Windows. So the message-loop in WinMain is blocked, messages
sent by Windows accumulate in the message queue, and you are not processing
them.
This is why worker threads are useful: the main GUI thread can process the
message queue continuously (so the GUI can react to e.g. user's input), and
the worker thread can do its lengthy job in the background, without blocking
the message-pump loop.
HTH,
Giovanni
other reason..