From: Michael Schnell [mailto:[email protected]] 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 -- _______________________________________________ Lazarus mailing list [email protected] http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
