[Lazarus] Sending messages

Mattias Gaertner nc-gaertnma at netcologne.de
Sat Nov 26 00:07:31 CET 2011

On Fri, 25 Nov 2011 22:57:34 +0100
Hans-Peter Diettrich <DrDiettrich1 at aol.com> wrote:

> zeljko schrieb:
> > On Friday 25 of November 2011 14:33:16 Hans-Peter Diettrich wrote:
> > 
> > 
> >  > And how does PostMessage fit into the picture?
> > 
> > 
> > I'm using PostMessage in an audio application to update position of 
> > trackbar on mainform from another thread where audio file is loaded and 
> > playing and it works ok (tested qt and gtk2)
> This looks like PostMessage is thread-safe, but is not a proof.

Yes, PostMessage is thread safe.
The PostMessage function places (posts) a message in the message queue
and then returns without waiting.
The SendMessage is not thread safe and executes immediately.
> About multiple queues: do LCL forms have an owning thread?

Maybe some widget sets have that internally.

> On Windows the owning thread is part of the window class data, but what 
> about other widgetsets?
> > ... and of course you 
> > cannot test result of PostMessage since it can be executed at any time 
> > after posting (depends when WS event queue will process your message)
> That's documented behaviour.
> > If you need to check for result you must use SendMessage() but in that 
> > case you cannot use it from another thread (at least it does not work 
> > with qt and gtk2 as I expected or I've misunderstood point of 
> > SendMessage()).
> I just wonder how a broadcast (to HWND_BROADCAST) works with 
> SendMessage. But this is a feature that must not be supported for 
> non-Windows platforms.

Do you mean "need not"?

> > Qt have similar mechanism: SendEvent() & PostEvent() and it works in 
> > same way.
> Are threads supported?
> The more I try to understand the Lazarus message handling, the more 
> questions arise :-(

QT functions are beyond the LCL docs.

> Here's a snippet from the WinAPI SendMessage docs:
>  >>
> If the specified window was created by the calling thread, the window 
> procedure is called immediately as a subroutine. If the specified window 
> was created by a different thread, the system switches to that thread 
> and calls the appropriate window procedure. Messages sent between 
> threads are processed only when the receiving thread executes message 
> retrieval code. The sending thread is blocked until the receiving thread 
> processes the message. However, the sending thread will process incoming 
> nonqueued messages while waiting for its message to be processed.
> <<
> The last sentences imply that the LCL *must* be reentrant, when 
> intra-thread messages are implemented. But what about possible deadlocks 
> then?

The LCL does not support creating windows from other threads.
You can try doing that by calling the appropriate widget set functions
yourselves. But I don't know if that will work.
So, your question is somewhat theoretical, isn't it?


More information about the Lazarus mailing list