The reason for TranslateMessage()?

[Dval]

Hi guys,

I'm studying windows programing. I'm currently trying to figure out windows messages. I've run into the TranslateMessage function. I've done some searches and haven't come up with a good answer yet. I can't seem to grasp why you need to translate a window message into a thread message. If my app handles the incoming messages to the current window why would I want to turn that message into ( I'm assuming ) and equivalent thread message? Shouldn't handling it within the
WindowProc be sufficient?

Thanks for your input,
Dval

[guestgulkan]

Windows GUI tend to follow a common trend:
Step:
1. Register a Window Class;
2. Create a (main) window of that class.
3. Enter the message loop.

You also provide a window procedure to handle message for the window you created.

The message loop generally looks like something like this:

{
   MSG msg;
   while (GetMessage(&msg, NULL, 0, 0) > 0) {
     TranslateMessage(&msg);
     DispatchMessage(&msg);
   }
   return msg.wParam;
 }

This message loop gets messages from your window queue.
Now this look like all windows messages for your window will go through this queue - but that is not true.
Most messages that windows generate for your application are sent directly to your Window Procedure.

Some message types that go through the queue and therefore are picked up and despatched by this loop are:
WM_PAINT
keyboard related messages.
mouse related messages

Now keyboard related messages arrive in the queue as Virtual key codes - the prupose of the TranslateMessage() function is to translate keyboard messages into WM_CHAR messages.

The DespatchMessage() function sends the message off to the window procedure.

[webJose]

guestgulkan, do you have an online reference that backs up the following?

Most messages that windows generate for your application are sent directly to your Window Procedure.

I find that very unlikely because you cannot just "inject" a function call into a thread. The closest would be QueueUserAPC() when the thread is in an alertable wait state. I don't think GetMessage() puts the thread in such a state.

I would like to see this written elsewhere.

[z05DSL3A]

Message Routing
The system uses two methods to route messages to a window procedure: posting messages to a first-in, first-out queue called a message queue, a system-defined memory object that temporarily stores messages, and sending messages directly to a window procedure.

http://msdn.microsoft.com/en-us/library/ms644927(VS.85).aspx#routing

[webJose]

Thanks! Reading...

[webJose]

Ok, I read it. It's true! But I don't get it. I'll post a new topic.

[Dval]

Ok. Let me see if I've got this.

The message queue that this loop is reading from is not the queue that my WindowProc is handling? If I got that right then the the use of TranslateMessage can't or shouldn't be decoupled from the use of DispatchMessage right? So its seems you are given a chance to handle some messages before they reach the WindowProc right? I guess if I'm getting this right then I've got a big question as to the purpose of two queues. Why have to manage two? And furthermore, is it up to the coder where the messages incoming on the window queue are injected into the thread queue?

One other thought,
If anyone knows of a good place to read about the why's and not just the hows of these processes it would be much appreciated. I find that I can very quickly figure out how something works with internet searches but as for the whys... well those answers don't come so easy.

Thanks,
Dval

[webJose]

There are NOT 2 queues. It is just one message queue that gets dequeued by one message loop.

The window procedure is just the convention Microsoft set to handle any message, either queued or not queued.

So, the message loop has the sole purpose of dequeuing, while the Window Procedure has the sole purpose of reacting to individual messages. Two different objectives handled by two different pieces of code. Both objectives happen to deal with the same structure, though (the MSG structure).