Re: a *working* PostThreadMessage() implementation...?
On Thu, 2 Oct 2008 05:26:38 -0700 (PDT), ".rhavin grobert" <clqrq@yahoo.de>
wrote:
On 2 Okt., 00:02, "Doug Harrison [MVP]" <d...@mvps.org> wrote:
I meant it would be better than trying to roll one's own message queue to
work around the PostThreadMessage issues. In order for PTM to work right,
all message loops have to account for it, which could be a problem down the
road if you add a secondary message loop for some reason.
?
there are only two acceptable scenarios:
1: Message IS delivered to the treads message queue and WILL appear in
the threads own message loop
2: Message cant be delivered and the posting-Fn return an error.
Then you should be happy with PostThreadMessage, because it satisfies those
two criteria. Seriously. The problem occurs when one or more message loops
the thread runs fail to handle messages posted by PostThreadMessage. Again,
if you use PostMessage to a (hidden) window, any message loop that uses
DispatchMessage will handle things fine. In order to run into a problem
with PostMessage, the message loop would have to eat a message it knows
nothing about, which would be a rare bug.
I post a mesage to a thread and expect the thread to receive it. thats
it. If the thread doesnt process it right now because it displayes a
message box, draws a button, hacks the White House or has fun leaking
memory, i expect the message to stay in the queue.
Well, PostThreadMessage requires special handling as previously described.
if ANOTHER thread
is currently doing $whatever i expect the message queue of my thread
undisturbed. As PostThreadMessage() doesnt fulfill those simple
expectations, i assume it poorly implemented and do it myself.
I hope you appreciate the flaws in that conclusion now.
--
Doug Harrison
Visual C++ MVP