Re: The basics of Windows' messages

First of all, I would like to thank you and Arnaud for taking the time to respond. I have appreciated your feedback.

William DePalo [MVP VC++] wrote:

[...]

Yes. That's pretty much it as far as messages that are posted go. Messages may be sent as well. In the case of messages sent _across_ processes, the sender is blocked until the receiver processes the message. When the receiver next calls GetMessage() or PeekMessage(), Windows will note that there is a sent message pending, and it will route it to the traget window before fetching the next message from the queue.

So I guess /SendMessage/ could be seen as a way of sending "priority messages" in a synchronous way. Not only will the sender block until the message is actually processed, but the receiver will prioritize the sent message. Thanks for adding that description.

As a next step in my attempt to unearth and check my grasp of Windows' workings, I would like to bring up a related issue that has been bothering me for some time. It has to do with the way to handle events that require lengthy processing. As I understand it, and based on the concepts discussed previously, event handlers are supposed to act briefly so that the application's thread can attend to pending messages. What should be done when an event (e.g. a button click) launches a heavy/lengthy process?

If no special measure is taken, the consequences are anything but nice. As mentioned in your response, if an application does not process messages timely, it will appear to be hung; in other words, it will not be responding to the user's input, requests for repainting by the system, etc.

The two workarounds for this situation which I know are:

1) write the lengthy processing as a separate thread; or
2) force the application to periodically deal with its message queue.

I would like to focus on item 2) for now. What I have seen is that many (if not all) Windows development frameworks offer some facility to achieve that, even if under different names. For example, Borland's VCL's /TApplication/ class has a method called /ProcessMessages/. Visual Basic, on its turn, offers a function called /DoEvents/. For the purposes of this message, I will use /ProcessMessages/ to refer to them.

My problem is in understanding how and what those functions actually do. In particular, I would like to have a clear vision of who does what (as in Windows versus the thread calling /ProcessMessages/). My confusion comes mainly from the fact that the documentation for those facilities usually state that they make the calling thread yield "execution so the operating system can process other events." [1]

Does "yield" in that case mean what I think it does? In other words, does the code in /ProcessMessages/ actually cause a switching of the execution context? Or does it run in the context of the calling thread? Supposing that context swithing actually takes place; then, which thread actually processes a message after it is removed from the queue? I thought all event handlers for messages of a given thread were executed in the context of that very thread, not any other one.

I could imagine something like a loop that would run until the queue is empty, but I wish to know who (what thread) actually does it and when is it that control is returned to the calling thread, so that it can resume execution of the instruction that follows the call to /ProcessMessages/.

I apologize for the length of my post. I wonder whether it should have been written in a separate thread (pun intended). Anyway, I would be pleased if I could once again benefit from the valuable input of this forum's members.

[1] http://support.microsoft.com/kb/q158175/

Best regards,

--
Ney André de Mello Zunino
.