Windows Programming Questions

SECTION- MESSAGE HANDLING

1, Explain the message routing mechanism in a windows application.

Every windows application has an application object which has a main thread. Remember CWinApp is derived from CWinThread. The main thread has a message queue associated with it. Summarize it like this - Every application has a message queue.Windows places the input messages to the application in this queue or sends it directly to the window procedure. So we have two types of messages based on queuing.

a. Queued Messages

Every thread has a message loop which pops the message from the queue, fill it in a MSG structure and dispatches to the appropriate window of the application. This is encapsulated in Run member function of CWinApp inherited from CWinThread. By dispatching I mean call the window procedure of the window class with message parameters. The window procedure handles the messages based on the message type.

A typical message loop implementation looks like this.

MSG msgstruct;
BOOL bResult;

while( (bResult = GetMessage( & msgstruct, NULL, 0, 0 )) != 0)//POPS from the queue
{
if (bRet == -1)
{
// error handling
}
else
{
TranslateMessage(&msgstruct); //Convert virtual key code to WM_CHAR
DispatchMessage(&msgstruct); //Fill MSG structure & calls the window procedure
}
}

b. Nonqueued Messages

Nonqueued messages are sent directly to the destination window procedure, bypassing the system message queue and thread message queue
Eg: WM_ACTIVATE

2. How to handle a message before it reaches TranslateMessage?

OverRide CWnd::PreTranslateMessage and handle the message in it.

3.What are the types of windows messages?

Based upon queuing there are two types of messages ie; queued and non-queued.
Based up on the definition there are two types of messages ie; System-Defined Messages and Application-Defined Messages(starts from WM_USER)

System defined Messages are classified into 3 categories again.
a.Windows messages
All messages beginning with the WM_ prefix, except for WM_COMMAND comes under this. Handled by windows and views. They have parameters that are used in determining how to handle the message.

b.Control notifications
These are WM_COMMAND notification messages from controls and other child windows to their parent windows.For example, an edit control sends its parent a WM_COMMAND message containing the EN_CHANGE control-notification code when the user has taken an action that may have altered text in the edit control. The window's handler for the message responds to the notification message in some appropriate way, such as retrieving the text in the control.
Routing is same as other WM_ messages except the BN_CLICKED notification message which is treated specially as a command message and routed like other commands.

c.Command messages
WM_COMMAND notification messages from user-interface objects: menus, toolbar buttons, and accelerator keys. There is a special order for handling these mesages called as Command Routing.

4. How Command messages are treated differently fro other messages?

Commands can be handled by a wider variety of objects: documents, document templates, and the application object itself in addition to windows and views. There is a standard routing order for handling command messages(Command Routing). The other messages are used to populate the MSG structure and passed to window procedure of the target window.

5. How does a window handles incoming messages?

At run time, each window is attached to a window object that has its own associated message map and handler functions. The framework uses the message map to map incoming messages to handlers.

6. Which is the MFC base class which implements the ability to send and recieve windows messages?

CCmdTarget

7. What is a message map?

A message map is a structure which routes commands or messages to a window to the member functions of the window class. (A command is a message from a menu item, command button, or accelerator key.)

8. How a messae map is different from virtual table mechanism in C++?

When ever a window recieves a message it chcks message map of itself to handle the message. If not found in its window class, it searches the immediate base classes message map for a handler. The virtual table of the window doesn't contain the pointer to the handler of the message if it is not overriden in the window class. In a virtual table mechanism in C++ the function pointer to a virtual function is in the virtual table even if it is not overriden in the derived class. The advantage of MFC message map mechanism is that with deep levels of class heirarchy it is able to provide a lot of functionality inhritance with out a virtual table bloat.