Home | Overview | How Do I | Tutorial
Your responsibility in working with commands is limited to making message-map connections between commands and their handler functions, a task for which you use ClassWizard. You must also write most command handlers.
Windows messages are usually sent to the main frame window, but command messages are then routed to other objects. The framework routes commands through a standard sequence of command-target objects, one of which is expected to have a handler for the command. Each command-target object checks its message map to see if it can handle the incoming message.
Different command-target classes check their own message maps at different times. Typically, a class routes the command to certain other objects to give them first chance at the command. If none of those objects handles the command, the original class checks its own message map. Then, if it can’t supply a handler itself, it may route the command to yet more command targets. The table Standard Command Route below shows how each of the classes structures this sequence. The general order in which a command target routes a command is:
How expensive is this routing mechanism? Compared to what your handler does in response to a command, the cost of the routing is low. Bear in mind that the framework generates commands only when the user interacts with a user-interface object.
| When an object of this type receives a command . . . | It gives itself and other command-target objects a chance to handle the command in this order: |
| MDI frame window (CMDIFrameWnd) |
|
| Document frame window (CFrameWnd, CMDIChildWnd) |
|
| View |
|
| Document |
|
| Dialog box |
|
Where numbered entries in the second column of the preceding table mention other objects, such as a document, see the corresponding item in the first column. For instance, when you read in the second column that the view forwards a command to its document, see the “Document” entry in the first column to follow the routing further.