Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / lazarus / 2009-01

Dispatching GUI messages from background threads

5 messages · 3 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

David W Noon

Hi,

I have declared a couple of procedures with the message attribute in a form class, descended from TForm, like so:

    procedure Log_message(var msg: UserMsg); Message LM_USER;
    procedure Thread_complete(var msg: UserMsg); Message LM_USER+1;

The structure UserMsg has a Cardinal in the first position to hold the message id. This is always set correctly to one of the two values based on LM_USER, as above.

The background thread's class, descended from TThread, contains a pointer to the form that invoked the thread in a field named Parent_form.

When the background thread comes to post a message to the parent form, it uses the Dispatch() method of TObject, inherited through TForm to the form's class. However, the call never returns and the application hangs. I have also tried the DeliverMessage() function, but the results are identical.

This looks rather like some sort of deadlock on something like a mutex semaphore -- but that's just a guess. Is there some "knack" to calling Dispatch() that avoids this problem?

Regards, Dave [RLU #314465] ====================================================================== (David W Noon) ======================================================================

Reply by email

Hans-Peter Diettrich
to David W Noon
This looks rather like some sort of deadlock on something like a mutex semaphore -- but that's just a guess. Is there some "knack" to calling Dispatch() that avoids this problem?

The solution is simple: don't use Dispatch() from a thread, use the thread-safe SendMessage instead.

DoDi

Reply by email

David W Noon
to Hans-Peter Diettrich
Hans-Peter Diettrich wrote 8 lines
David W Noon schrieb: > This looks rather like some sort of deadlock on something like a mutex > semaphore -- but that's just a guess. Is there some "knack" to calling > Dispatch() that avoids this problem? The solution is simple: don't use Dispatch() from a thread, use the thread-safe SendMessage instead.

The only function like that I could find was SimpleSendMessage(), which produced the same result as Dispatch() and DeliverMessage(), but without supplying any message data. In which unit is SendMessage() defined?

I finally resolved the issue by changing the pointer to the form into an object reference to a TObject. After that, Dispatch() worked as documented (such as it is documented).

Moreover, the action I needed was a "post", not a "send". It is the "send" style of message transfer that causes deadlocks between the worker thread and the user interface thread. This is because "send" waits for a return code from the message handler, whereas "post" just places the message on the queue and proceeds regardless.

Regards, Dave [RLU #314465] ======================================================================= (David W Noon) =======================================================================

Reply by email

Paul Ishenin
to David W Noon
David W Noon wrote
The only function like that I could find was SimpleSendMessage(), which produced the same result as Dispatch() and DeliverMessage(), but without supplying any message data. In which unit is SendMessage() defined?

add LCLIntf unit to your uses section and you'll get SendMessage and PostMessage.

Best regards,
Paul Ishenin.

Reply by email

David W Noon
to Paul Ishenin
Paul Ishenin wrote 8 lines
David W Noon wrote: > The only function like that I could find was SimpleSendMessage(), which > produced the same result as Dispatch() and DeliverMessage(), but without > supplying any message data. In which unit is SendMessage() defined? add LCLIntf unit to your uses section and you'll get SendMessage and PostMessage.

Both methods of message transfer! Many thanks.

Regards, Dave [RLU #314465] ======================================================================= (David W Noon) =======================================================================

Reply by email