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