posted March 06, 2004 08:07 PM            

The problem with PostMessage was this:

The tests I ran were where the thread would calculate coordinates
, pass a message back to the main GUI thread to draw what the
thread designed, and then the thread would continue on an
calculate again. I was creating an animation where the thread
was running constantly and requesting the main thread to draw
what it designed.

When I posted the messages this is what happened:

The main GUI thread would get a message which requested an image
be drawn. It would draw the image on a memory DC and then invalidate
the client area so WM_PAINT would be generated. When WM_PAINT occured
the memory DC is BitBlt'ed to the client area.

Windows waits until no messages are pending before WM_PAINT
is generated.

What happened when I posted messages, the GUI thread would draw
the image, but the thread ended up posting the redraw messages
too fast and then main thread could not keep up. A backlog of
messages occured for some reason. Basically the program became
unstable. Whether the backlog was the WM_PAINT or just the
posted message itself wasn't apparent, but either way a backlog
occured.

When I switched to using SendMessage which forced a context switch
the problem disappeared and the main GUI thread kept up with the
worker thread (or maybe it was the worker thread was forced not
to go too fast because it had to wait on the return of sendmessage
from the main thread).

Because posting a message doesn't require the message to be
processed before the thread moves on, this is the inherent
danger of posting IMO.

The use of SendMessage forces a context switch so you have more
control.

The EZGUI program noted above, displays two different animations
using two threads simultaneously at high speed. This was the test
I used when adding thread support to EZGUI 3.0.

My comments are based on an actual real life test and the need
to find a solution.

EZGUI 3.0 does support posting a message from a thread, but it
also has a tracking system so the thread knows how many pending
messages exist. Without this tracking system, posting messages
would not be reliable IMO. There must be a system to prevent
a backlog of posted messages and that is what I implimented.

I am not concerned about any "recommended" method in books, but
only in what works.

I did do a good bit of research into using threads before deciding
the best solution.

posted March 06, 2004 11:15 PM            

quote:

---

Because posting a message doesn't require the message to be
processed before the thread moves on, this is the inherent
danger of posting IMO.

---

quote:

---

The use of SendMessage forces a context switch so you have more
control.

---