[Lazarus] SendMessage Bug Work Around.

[Duncan Parsons]

From: Michael Schnell [mailto:mschnell at lumino.de] 
Sent: 23 April 2010 14:16

>On 04/23/2010 11:58 AM, John vd Waeter wrote:
>> AFAIK: In Windows
>>
>> PostMessage puts a message in the queue and returns immediately.
>>
>> SendMessage puts the message in the queue and returns with a result 
>> after the message has been handled.
>>
>> But I might be wrong...
>
>You might be right.
>
>Yet, I only played with SendMessage to do communication between two or
more Delphi applications in Windows. Here the receiving 
>functionality is "procedure ... message" and I did not find a
documentation that states that the sending process (better: thread) is 
>supposed to be blocked in SendMessage until the receiving process
finished it's message procedure.
>It should be easy to try this by doing a sleep in the message
procedure, but the result might be invalid, as the receiver's RTL could
first >acknowledge the message to the System (whatever that means) and
only call the pascal code afterwards.
>
>-Michael

<Paper Vendor> 'Read all about it!'
http://msdn.microsoft.com/en-us/library/ms644950(VS.85).aspx </Paper
Vendor> :-)

Some years ago I had to re-organise my handling of some
SendMessage/WM_COPYDATA interactions, since the receiving application
would launch a modal dialog which blocked the sending app until the
whole process was done. The user would be confused as to why they
couldn't refer back to the original app until they had completed the new
input dialog that had been launched.

I worked around it by copying the relevant data on receiving the
message, and instantiating a 1ms timer to call the correct procedure;
the receiving process could then return quickly, and the sending app was
no longer blocked. The timer fired the correct dialogs, and the user was
none-the-wiser as to the underlying spaghetti that had happened. It was
a little hacky, but worked well :-)

DSP