There is a nice example in the MSDN Library, which illustrates the
use of the MsgWaitForMultipleObjects function in a message loop:
http://msdn2.microsoft.com/en-us/library/ms687060.aspx
The title of the example is 'Waiting in a Message Loop'.
I have a question about this example:
If the program enters an internal message loop and stays there for a
while (for example, when the user presses down the mouse button on
the scrollbar, which generates a WM_NCLBUTTONDOWN message, which
causes a Windows internal message loop to be started) then how can I
know whether one of the handles became signaled ?
Many thanks in advance!
Laszlo
In any case, maybe you could do it architecturally: say, if your handles
must have priority over your window message processing, I believe you could
always create another thread to manage and react to them, posting Windows
messages to the UI thread as needed: it would handle them eventually.
I would think that you could redo the processing so that each iteration does
a MsgWaitForMultipleObjects and processes one message if available. Sort of
like:
<untested>
while (true)
{
DWORD dwResult = MsgWaitForMultipleObjects(..);
switch (dwResult)
{
case WAIT_OBJECT_0:
break;
(more cases)
default:
if (PeekMessage) {
DispatchMessage();
}
}
}
Mike P
--
Ken Johnson (Skywing)
Windows SDK MVP
http://www.nynaeve.net
"Laszlo Nagy" <Laszl...@discussions.microsoft.com> wrote in message
news:BD0BFD0C-1779-4E55...@microsoft.com...
Oh, and you though not strictly required, you can defer the testing
available messages via PeekMessage until MsgWaitForMultipleObjects returns
``WAIT_OBJECT_0 + nCount''. That is, it is not strictly necessary to poll
the message queue each time the function returns, only when you get a
``WAIT_OBJECT_0 + nCount'' notification.
--
Ken Johnson (Skywing)
Windows SDK MVP
http://www.nynaeve.net
"Mikep" <mi...@NOSPAMturboware.com> wrote in message
news:uCZq6EZv...@TK2MSFTNGP02.phx.gbl...
Many thanks.
Laszlo
You could put the monitoring of those events in a separate worker
thread - which would probably mean that you wouldn't need to use the
MsgWaitForMultipleObjects variant.
Dave
--
Ken Johnson (Skywing)
Windows SDK MVP
http://www.nynaeve.net
"Laszlo Nagy" <Laszl...@discussions.microsoft.com> wrote in message
news:0A28CD44-23DB-4E8A...@microsoft.com...