[Lazarus] Sending messages

[Mattias Gaertner]

On Sat, 26 Nov 2011 11:50:53 +0100
Hans-Peter Diettrich <DrDiettrich1 at aol.com> wrote:

> Felipe Monteiro de Carvalho schrieb:
> > On Fri, Nov 25, 2011 at 2:33 PM, Hans-Peter Diettrich
> > <DrDiettrich1 at aol.com> wrote:
> >>>> This doesn't answer my question. What's the *source* of the processed
> >>>> messages?
> >> And how does PostMessage fit into the picture?
> > 
> > If this is for writing documentation, then you are clearly on the
> > wrong track here. Libraries work with the black box concept. The user
> > does not need to know where the messages from PostMessage are stored,
> > they are stored "somewhere" and will reappear "sometime later" in the
> > main thread. That's enough.
> 
> It's not enough *if* messages can end up in different message queues, 
> and when the user has to implement explicit message handling e.g. in 
> threads.

Maybe you should give people some time to answer your mails, before
writing several mails all based on the same misunderstanding.

The LCL is event driven, and it does not matter how many event queues
there are behind the scenes.
As always it gets a more complicated with multithreading. Other
threads can only produce events via PostMessage, QueueAsyncCall,
TThread.Synchronize or RTL functions.
In any case the LCL executes the events only via the main thread. 

 
> > Any information of "where" the messages were in between is an
> > implementation detail which can change at any time. It also changes
> > from widgetset to widgetset.
> 
> You already mentioned multiple message loops in the LCL. That's fine 
> when a user does not have to care about these loops. I only want to know 
> whether (and how) a user may have to provide explicit message handling code.
> 
> E.g. it's well known that a single-threaded applications should call 
> Application.ProcessMessages during lengthy tasks, in order to keep the 
> GUI responsive. Is something like that required in threads, too, or what 
> else is the suggested way for inter-thread communication, instead of 
> sending messages?

The Application.ProcessMessages is only needed by the main
thread and must only be called by the main thread (like most LCL
functions).

 
> E.g. TWidgetset.AllocHWND allows to create (hidden) windows, which then 
> can receive messages. Does this allow to send messages to threads, on 
> *all* platforms? Such functionality IMO *can* be implemented in the LCL, 
> for all widgetsets, question is whether it will be supported *by 
> design*, or only exists for Delphi/Win32 compatibility?

TWidgetset.AllocHWND is WinAPI specific.
If you use this you leave the safe harbor of the LCL.
Then you have to read the WinAPI docs and see the implementation of the
LCL interface code, e.g. for win32.

Mattias