Why are messages sent using "PostMessage" getting lost ?

[Ivan]

Hi,

I have a thread created using the Non-MFC "CreateThread" function,
sending user-defined messages to the main application window using the
Non-MFC "PostMessage" function. The rate at which these messages are
being sent is approximately 100 per second.

The problem is that some of these messages are not being received by the
user-defined message handling function.

Is there a limit on the size of the receivers message queue, if so, how
can you detect this and perform any necessary flow control ? Or am I
doing something very wrong.

Please help.

Best Regards,

Ivan.

[Damian Driscoll]

>Is there a limit on the size of the receivers message queue, if so, how
>can you detect this and perform any necessary flow control ? Or am I
>doing something very wrong.

No, there was a limit in win16 but win32 expands queues dynamically. In any
event it sounds like you should be calling a function instead.

[Pušiæ Goran]

>The rate at which these messages are
>being sent is approximately 100 per second.

This sure is a lot! The problem is if your app and machine can handle this
amount of messages. Suppose handling one of them lasts more than 10 ms.
Message queue will eventually be overflown (pardon my English, is
"overflown" correct?).

Anyway, I tried once to PostMessage until it returned FALSE. At 64MB RAM,
about 150MB swap file system, PostMessage failed after about 300,000 calls
in the queue. What's interesting, the system then crashed, and I even had to
reinstall it. I doubt PostMessage was the reason, though, but just to warn
you.

Pehaps you should try some other mechanism of communication between threads?
Say, shared data with synchronized access and PostMessage at every, say, 100
or so changes in data?

[Bob Rundle]

Do you have a modal dialog box up when you lose messages? Your highly
important WM_USER messages become chaff on the main thread whenever a modal
dialog box appears.

The solution is to create a separate user interface thread and send the
messages there.

Ivan <Iv...@imag.u-net.com> wrote in message
news:3779DA7A...@imag.u-net.com...

>
> Hi,
>
> I have a thread created using the Non-MFC "CreateThread" function,
> sending user-defined messages to the main application window using the

> Non-MFC "PostMessage" function. The rate at which these messages are

> being sent is approximately 100 per second.
>

> The problem is that some of these messages are not being received by the
> user-defined message handling function.
>

> Is there a limit on the size of the receivers message queue, if so, how
> can you detect this and perform any necessary flow control ? Or am I
> doing something very wrong.
>

[Dave]

The docs state post message can fail, did you check for error returns from
PostMessage?

Also..If you send that many to your main UI thread it will probably swamp it
and the main UI thread will become unresponsive. Best bet is to store the
information in some other structure that can be polled by the UI thread so
that the UI thread can decide how to deal with the whole lot of information
at once rather than try to deal with it a message at a time.

Ivan wrote in message <3779DA7A...@imag.u-net.com>...

[Raymond Chen]

You shouldn't be posting 100 messages per second. Try coalescing
them or posting only on transitions.
--
(My return address is intentionally invalid; delete ".---" to get my real address.
My responses are not to be considered official technical support or advice.)

[Doug Harrison]

Joseph M. Newcomer wrote:

>If PostMessage (or ::PostMessage--you should be able to use the MFC
>PostMessage function in any case) fails, it returns a FALSE value.
> VERIFY(AfxGetMainWnd()->PostMessage(...));
>should tell you if it is ever failing (don't do ASSERT, or your PostMessage
>will disappear in the release version).

Don't use VERIFY either. Since he's concerned about dropping messages,
presumably, that's an error he needs to handle, e.g.

while (!PostMessage(...) && !quitThread)
Sleep(0);

--
Doug Harrison
dHar...@worldnet.att.net
Visual C++ MVP

[Doug Harrison]

Bob Rundle wrote:

>Do you have a modal dialog box up when you lose messages? Your highly
>important WM_USER messages become chaff on the main thread whenever a modal
>dialog box appears.

You're thinking about messages posted by PostThreadMessage. A modal dialog
runs a message loop internal to Windows and dispatches window messages,
including WM_USER. As documented, WM_APP is a better choice of basis for
user-defined messages, though.

[Joseph M. Newcomer]

If PostMessage (or ::PostMessage--you should be able to use the MFC
PostMessage function in any case) fails, it returns a FALSE value.
VERIFY(AfxGetMainWnd()->PostMessage(...));
should tell you if it is ever failing (don't do ASSERT, or your PostMessage
will disappear in the release version).

joe

Ivan <Iv...@imag.u-net.com> wrote in message
news:3779DA7A...@imag.u-net.com...
>