Win32 API is Microsoft's operating system Windows to provide developers' programming interfaces, which determines the ability of our development of Windows applications. MFC is Microsoft's class library provided by developers, in a sense to encapsulation of Win32 APIs. This paper tries to understand the concept model of both Win32 API and MFC from the global perspective. This article uses the UML description concept model. Win32 API is not object-oriented, I use the object-oriented point to understand it, nothing to express their overall situation. I. Concept model of Win32 API Win32 API's Object has three types: User Obj, GDI Obj, Kernel Obj. However, if you don't consider the support of the OS itself, you will be confused on some questions, so I will put "Operation System to be encapsulated into message" here. 1, the relationship between 4 of User Obj, GDI Obj, Kernel Obj, System is responsible for the Kernel Obj part, so we directly go directly into the Kernel Obj part in the following image. As seen from the figure, in memory, in addition to "being encapsulated into a Message" SYSTEM support section, there are also three types of Object: kernel obj, user obj and gdi obj, each Obj has a handle Handle Corresponding. Among them, GDI OBJ established the contact of Windows application and external output devices to be developed, and the file in Kernel Obj establishes the contact of memory and permanent storage devices. Specifically, the file in memory can be from the hard disk. If this file is an executable, it will generate module, and module is running is process. The process can contain multiple Thread, and the running image of Thread is ultimately from File . Thread is the most important one in kernel obj, because the message queue is THREAD owned, only Thread can accept Message. The operation of GDI OBJ, URSER OBJ and FILE is also in Thread. Therefore, books say that process has at least a Thread. 2. Expand "SYSTEM is responsible for encapsulation into a Message" section "System is responsible for encapsulation into a message" section, and the confusion of "How to Form" as soon as possible. 3, expand the "GDI OBJ" section
Developers can feed back the information of the app to the USER via GDI Obj. As seen from the figure, GDI Obj has 8 kinds, 7 of which: BMP, Brush, Pen, Region, Font, Palette, Path. Another more special is DC, which can be understood as a container, the programmer puts the PallTE into the container by calling SelectPallette (), puts beginpath () and endpath () put the PATH into the container, other 5 GDIs Obj is put into the container by calling SelectObject (). DC is divided into four, where displaydc is the most commonly used DC used to support us "painting WINDOW". Also, if you feel bad, please refer to the Composite design mode. 4, expand the User Obj section
4.1 1st iteration
Window has an important role in Windows application development. As seen from the figure, Window can be divided into 3: Desktop, Top-Level Window, Child Window. All Windows is organized into TREE, there is a special data structure to manage. Desktop is the root, the child node of Desktop is Top-Level Window, the child node of Top-Level Window is Child Window, and Child Window can still have sub-nodes, which are also attribute at child window. 4 important information is recorded in the Tree data structure, 4 pointers: Parent pointers, Child pointers, Brother pointers, Owner pointers. In this way, you can easily find other Windows from any WINDOW. Ok, get the conclusion of Window = Desktop Toplevel Child, see the global first. After all, a step in place is sometimes not good. As seen from the figure, Window does possess an important role. From logic, thread is Window owner; however, all Windows determines that the screen looks above, let alone Click on any Window to make Window's mutual coverage, which is necessary to manage the WINDOW. Therefore, the OS has to unify use Window Tree to manage Window, reflect complex Window relationships. Every Window must have one and only one customer area, and there may be a Title Bar.
Let's take a look at what information is disclosed in Interface SPEC's Interface SPEC's INTERFACE.
As seen from the figure, CREATEWINDOW () is responsible for establishing contact with window classes for Window. Each Window has a window class with it, and one window class can correspond to multiple Windows. Resource information such as window functions and menus is recorded in the window class, and Module generated by File is the hometown of window functions and resources.
4.2 2nd iteration
Examination of message type. As seen from the figure, each Message is sent to a Window. Note that the MSG can be generated by the SYS code or by the API function. Further investigate WINDOW, go deep into TopLevel and Child.
As seen from the figure, the Overlapped style Window is one of top-level window, while another Popup style Window is essentially a special Overlapped style Window, although we are from Coding angle It is often not thinking so.
Still not good, because when we call the CreateWindow () API function, it feels clearly when you feel Child, Overlapped, and popup is "Window Style". I draw a picture. As seen from the figure, Control must be a Child style. Dialog must be a popup style, while the general Window can be arbitrary. 4.3 3 ITeration
Summary User Obj: CREATEDIALOG () function:
As seen from the figure, CREATEDIALOG () and CREATEWINDOW () The biggest difference is that it has a dialog template to support convenient custom Dialog interface. Note that Dialog is a special WINDOW, and there is a certain window class.
Second, MFC conceptual model
We have studied the "domain model" of Win32 API and has a comprehensive understanding of it. Below, the study of the MFC concept model, we focus on the research on App Framework. The Message Response / Pass Mechanism in the App framework is the most important. The Hook mechanism and the Message response / transfer mechanism are closely related, the latter is based on the former. 1. Hook mechanism may only know how the Hook mechanism can write a very "cattle", and I don't know that the MFC itself relies on the Hook mechanism. As seen from the figure, each hook has a pointer queue, each pointer pointing to a HookProc function, HookProc will be executed by the OS call in the appropriate timing. Hook is divided into different kinds, in fact, the type of hook determines what it will be executed by the OS call. Tip, you can take a look at the "Subscribe-Publish" design mode to assist in solutions. 2 MFC's installation of the Message response function
2.1 Memory installation of the Message response function in the API
The installation of the Message response function in the API is implemented by createWindow (), which links Window with a WindowClass, and the latter records the pointer to the Message response function. As for details, look at how to write with Win32 SDK or Win16 SDK write programs, where defWindowProc () is an API function, which is responsible for providing default messages, so the programmer only requires special processing messages.
int WINAPI WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance, PSTR szCmdLine, int iCmdShow) {WNDCLASS wndclass; ... wndclass.lpfnWndProc = WndProc; wndclass.lpszClassName = szWindowClass; ... RegisterClass (& wndclass); hWnd = CreateWindow (szWindowClass,. .....
2.2 Installation of Message Response Functions in MFC
The installation of the Message response function in the MFC is obviously more complicated, which is done when CWnd :: Createex () is called, which also uses the Hook mechanism.
We can guess how MFC is doing. The MFC supports Massage Map, making the response to the message in multiple Message Handler functions, not the API development is the centralized message processing function; so, if you have a special code to be responsible for "Retrieve Message Map Table" Call Message Handle. Message Map is to support programmers to handle the special message of him, then where is the default Message processing logic? The answer is that the "predefined window classes" used by MFC create Window Obj, which naturally has a default Message handler.
As seen from the figure, CWnd has member variables m_pfnsuper, member variable m_hwnd, member function onWndmsg (), and member functions defWindowProc (). Wnd :: OnWndMsg () is responsible for "Message Handle defined in Message Map" can handle the message, if you are processed to return true; CWnd :: DefWindowProc () is responsible for processing the MersSage default. The execution process is, first CWnd :: createex () is called, Window Obj and Window Class are created accordingly. At this time, the Window Class's WindowProc field stores the address of the predefined default processing function; because Hook creates a message in the listener window Therefore, the registered hookProc () will be called, it backed up the WindowProc field of the ClassWindow data structure to CWnd :: m_pfnsuper, and use setWindowlong () to change the WindowProc field of the ClassWindow data structure to :: AfxWndProc () address. When any of the Message arrives,: AfxWndProc () is called, as for its logic, smart, you must guess, first call wh :: OnWndmsg (), if the return value is false, also call CWnd :: DefWindowProc ), CWnd :: m_pfnsuper points to the default processing logic, will also be called in CWnd :: DefWindowProc (). Tip, there is actually a polymorphic situation. For example, you can search PWND-> WindowProc (NMSG, WPARAM, LPARAM); additional, OnWndMSG and DEFWINDOWPROC are virtual functions for CWND classes. If you feel that you don't understand it, it is best to create a project actually trace in VC . Below is a screenshot of calling the stack image when I tracked. 3. The SUBCLASS mechanism is seen from the figure that the SUBCLASS mechanism is based on the M_PFNSUPER of CWnd himself, and the installation of the "MFC" is very like. 4. The main related classes in Frame Work is the candidates for the Message Route, which is the one oncmdmsg () to complete the Message Route, forming the Chain of ResponsAbility mode.
5. Chain of ResponsAbility mode in Frame Work
The following figure is an object tree, and the message is propagated in both longitudinal and lateral direction.
The message is transmitted in the longitudinal direction, is the "Massge Map table" traceable parent class ", the MFC's Message Map is completely taken to replace the virtual function, and the Message Route is independent.
The message is passed in the horizontal direction is the Message Route, which is the CHAIN OF RESPONSABILITY mode, which is completed together by multiple related classes onOncmDMSG ().
Third, summarizing the discussion from above is not difficult to find that MFC uses a lot of design patterns, as mentioned above, the Chain of ResponsAbility mode, Composite mode, and Subscription-Publishing mode. The above discussion not only helps programmers to fully master Win32 API and MFC, but also have a great help to Architect design Architecture.
