Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

MsgWaitForMultipleObjects & internal message loop

353 views
Skip to first unread message

Laszlo Nagy

unread,
Jul 2, 2007, 3:30:01 AM7/2/07
to
Hi!

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

Luis Gonz

unread,
Jul 3, 2007, 12:10:01 PM7/3/07
to
I don't know an exact answer but now I will be waiting for one too ;-)

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.

Mikep

unread,
Jul 3, 2007, 12:43:01 PM7/3/07
to

"Laszlo Nagy" <Laszl...@discussions.microsoft.com> wrote in message
news:BD0BFD0C-1779-4E55...@microsoft.com...

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


Skywing [MVP]

unread,
Jul 3, 2007, 9:40:07 PM7/3/07
to
Look at the return value from MsgWaitForMultipleObjects, just like the
example says. If one of the handles became signaled while you were blocking
in a function besides that particular MsgWaitForMultipleObjects call, when
you next get around to waiting on the handles via MsgWaitForMultipleObjects,
if any are already signaled then the function will return immediately with
the index of the first one checked that is signaled. If multiple were
signaled, then the function will return immediately with different return
values each time, each specifying the index of an event that is set, until
no handles are currently signaled.

--
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...

Skywing [MVP]

unread,
Jul 3, 2007, 9:44:47 PM7/3/07
to
That's incorrect. You should drain the entire message queue when you get
woken for a message queue event. This is because it is legal for the system
to collapse multiple wake notifications for the message queue into just one
notification, if multiple messages are queued by the time you get around to
calling MsgWaitForMultipleObjects again. (For what it's worth, all other
message queue wait functions, such as WaitMessage, also follow this
behavior.)

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...

Laszlo Nagy

unread,
Jul 4, 2007, 3:48:01 AM7/4/07
to
Hi!
Thanks for your answer, but I'm afraid, I have to rephrase the question.
Let's suppose the user presses the mouse button down on the scrollbar, then
does nothing else, that is, does not move the mouse and does not release the
scrollbar. In this case the program is waiting in an internal message loop
which means that MsgWaitForMultipleObjects is not called. In the meantime one
of my handles might have become signaled and I should react to that as soon
as possible but I can not react because I have no chance to find out that my
handle became signaled. So in a sense my program is hanged because the user
is unwilling to release the mouse button. Is there any way to find out that
my handle became signaled while the program is in an internal message loop?

Many thanks.
Laszlo

David Lowndes

unread,
Jul 4, 2007, 5:51:23 AM7/4/07
to
>Is there any way to find out that
>my handle became signaled while the program is in an internal message loop?

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

Skywing [MVP]

unread,
Jul 5, 2007, 2:04:07 PM7/5/07
to
Not for every case like that, no. The best bet there is to split your code
into a thread that deals with synchronization object handles and possibly
notifies the ui thread via window messages or something of that sort.

--
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...

Laszlo Nagy

unread,
Jul 6, 2007, 8:02:00 AM7/6/07
to
Hi!
I would like to thank everybody for the answers.
I have implemented the two threads solution.
Laszlo
0 new messages