PostMessage to a thread

[Jason Wilson]

I would like to use the Windows messaging mechanism to pass asyncronous FIFO
data between the main VCL thread and other threads spawned by the same
application/process. I have successfully managed to use the PostMessage
function to dispatch custom messages from the daughter threads to the main
VCL thread by creating custom message handler(s) on the various form(s).
However, I have *not* been able to send messages from the VCL thread to the
daughter threads.

I have declared a unique message ID:

const
WM_MYMESSAGE = WM_APP + 999;

I have created & implemented a custom message handler in my TThread
descendant:

TMyThread = class (TThread)
...
protected
procedure TWMMyMessage (var Message: TMessage); message WM_MYMESSAGE;
...
procedure TMyThread.TWMMyMessage (var Message: TMessage);
begin
//do something here
end;

I then post a message from the main VCL thread as follows:

PostMessage (MyThreadInstance.Handle, WM_MYMESSAGE, 0, 0);

I've even tried the following with no success:

PostMessage (MyThreadInstance.ThreadId, WM_MYMESSAGE, 0, 0);

Hell, I've even tried to implement the thread's DefaultHandler method to no
avail! The TThread class does descend from TObject so I think that it
*should* support message handling (?). Do I need to manually pull events
from the thread's message queue? Are there any other methods that need to be
overridden/implemented to facilitate message processing within a thread? Any
suggestions would be appreciated.

Sincerely,

Jason Wilson

[Eric Hill]

Messages are sent to *window* handles. You must create a window handle in
your thread to send messages to, and use that windows' message loop to pull
the messages out of the queue.

You can use the AllocateHWnd function (in Forms.pas) to get a window handle
that can be used inside a thread. Pass a message handler (defined in your
thread) to the function, and any messages sent to that windows' queue will
call your function.

Call the AllocateHWnd function from your thread's startup routine, NOT THE
EXECUTE routine. The window handle must be created in the context of the
VCL. The thread message handler needs to be inside the thread.

Eric

"Jason Wilson" <ja...@globestarsystems.com> wrote in message
news:3d013cbe$1_1@dnews...

[Jim Kueneman]

> Messages are sent to *window* handles. You must create a window handle in
> your thread to send messages to, and use that windows' message loop to pull
> the messages out of the queue.

Or use PostThreadMessage.

Jim

[Peter Below (TeamB)]

In article <3d013cbe$1_1@dnews>, Jason Wilson wrote:
> I would like to use the Windows messaging mechanism to pass asyncronous FIFO
> data between the main VCL thread and other threads spawned by the same
> application/process. I have successfully managed to use the PostMessage
> function to dispatch custom messages from the daughter threads to the main
> VCL thread by creating custom message handler(s) on the various form(s).
> However, I have *not* been able to send messages from the VCL thread to the
> daughter threads.

Messages are usually not a good mechanism for communications between secondary
threads. To be able to process messages a thread needs a message loop, which
only the main thread has by default. You can also only post a message to a
thread (with PostThreadMessage), not send it. SendMessage requires a window
handle as target. You can of course create a helper window in your threads via
AllocateHwnd (if you want the messages to be processed inside the thread the
window has to be created inside the Execute method of the thread, but beware:
AllocateHWnd uses MakeMethodInstance, which is not thread-safe!), but the
thread still needs a message loop to get the messages delivered.

A better way to pass data to another thread, IMO, is to implement a kind of
queue in the target thread. The thread would export methods to add data to the
queue, which would do that in a thread-safe manner (since the method executes
in the caller threads context) and then signal an event to wake the queues
owner thread up in case it is waiting for more work at the moment.

--
Peter Below (TeamB)
Use the newsgroup archives :
http://www.mers.com/searchsite.html
http://www.tamaracka.com/search.htm
http://groups.google.com
http://www.prolix.be