[Lazarus] SendMessage Bug Work Around.

Duncan Parsons D.Parsons at seamsltd.com
Mon Apr 26 12:12:17 CEST 2010


From: Michael Schnell [mailto:mschnell at lumino.de] 
Sent: 26 April 2010 10:00

.On 04/23/2010 05:37 PM, Duncan Parsons wrote:
.> Note in http://msdn.microsoft.com/en-us/library/ms644950(VS.85).aspx
.> where it says '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.'
.>   
.I did read this, but in fact I can't understand the meaning. If the
thread stops in "Send Message", it obviously is not in a
."waitForMessage" function. At what code would it start running if a
message to be processed arrives ?
.
.-Michael

Yeah, that second bit doesn't totally make sense to me either, but has
some truth in it in practise..

Scenario I used it in - In a job management system, the user types a
job/ticket number in one app (a dedicated viewer), but needs to make
modifications; those modifications are done in the editor app. The
viewer uses SendMessage with WM_COPYDATA which holds the job/ticket
number, and the type of edit. Whilst processing the message, the editor
opens a modal dialog to perform the edit.

If the user clicks back to the viewer whilst the modal dialog is open,
they cannot interact with the app in any meaningful way - it will not
repaint, it will not process mouseclicks in the client area, etc.
However.. It /will/ perform minimise/restore operations - so those
messages are clearly handled in a different manner to the others,
windows is doing something clever with the queues.

As I posted before, I solved this problem by extracting the data during
the message process, then instantiating a 1ms timer and returning. The
viewer was responsive straight away, and the editor's modal dialog
didn't interfere with anything else.

Don't know if that helps you!
Duncan




More information about the Lazarus mailing list