 |
 |
 |
 |
 |
 |
 |
|
Message Routing |
|
||
|
In document-view architecture, the WM_COMMAND message has a built-in
routing mechanism. This is because; a WM_COMMAND message can go to any of the
four classes in the architecture. So it is first routed to the view class. If a
handler function for that WM_COMMAND message is found in the view class, it goes
to that handler function, and the routing is complete because it does not go to
any other classes. If no handler function is found in the view class, the
WM_COMMAND message is next sent to the document class. If a response function is
present, the routing ends here. Otherwise, it proceeds to the mainframe class.
If no handler function is found, it proceeds to the application class. In the
document-view architecture, any of the four classes (application, mainframe,
view, or document) can contain a message map for WM_COMMAND messages. The mainframe class receives more normal (other than WM_COMMAND) WM_ messages than the view class does. For example, the mainframe can receive the WM_CLOSE message and will close. This is because; the view window cannot be closed. The mainframe class also gets involved in other activities that the view class is not allowed to participate in such as: session management, menu management, and change management. The view class occupies the entire client area and is the class that, most of the time, will handle the keyboard and mouse input WM_ messages. Thus we usually have the drawing functions located in the view class, and they will draw on the client area portion of the screen which, of course, is the view window. |
|||
 |
|||
| RELATED TOPICS | |||
|
Document-View
Architecture PreCreateWindow() Function OnDraw() Function Document Template RUNTIME_CLASS Macro CView Class Print from the View The Function OnPrepareDC() Mapping Modes Serialization using CArchive class Diagnostic Helpers |
|||
