[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?
No.
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?
Mattias
More information about the Lazarus
mailing list