Duilib study Note "01"-duilib the whole frame of understanding

From the Googlecode to download the Duilib project attached to a general design diagram (as shown below), you can first understand the overall, there is a preliminary understanding of the follow-up further in-depth study will be helpful.

With a preliminary understanding of the design diagram, the next step is to learn more about it, mainly from the following aspects of learning:
The composition of the library, framework basic flow, element creation mechanism, message processing mechanism.

1. Basic composition of the Library

1.1 Tools Library

Because Duilib does not rely on any external libraries, it implements many of the underlying classes used to support the project, as shown in it. These classes are distributed in the Util folder:

• UI Related: Cpoint/csize/cduirect
• Simple container: Cstdptrarray/cstdvalarray/cstdstring/cstdstringptrmap

Above these classes to see the name of the basic can understand its specific meaning, of course, in addition to the basic base library, there are some and window use related tools, such as window tools: windowimplbase, this tool we do not detail here, later use will be used frequently.

1.2 Control Library

The control library is divided into two blocks in the implementation of the Duilib: Core and control:

• The core contains all the parts that are common to all controls, which are mostly base classes and paint wrappers.
• Control contains the behavior of each of the different controls.

In particular, note the control base class Ccontrolui and the container base class Ccontainerui, which is an important part of the Duilib core class (as shown):

1.2.1. Control base class: Ccontrolui

Ccontrolui is important throughout the control architecture, which is the base class for all controls and the basic element that makes up the control tree, and all nodes in the control tree are a ccontrolui.
It basically includes all the common properties of the control, such as: position, size, color, whether there is focus, whether it is enabled, and so on. Of course, this class also provides a lot of basic functions for overloading to implement child controls, such as getting the control name and classname, whether it is displayed, and so on.
In addition, in order to facilitate the analysis of the various properties of the control directly from the XML, this class also provides a setattribute method, the property name and value passed in the string to set the specific properties, the inside is actually one by one to compare strings to complete, So it's better not to use it when you use it, because each property actually has a specific method to get and set.
In addition, there are several event-managed object--ceventsource in each control, which are triggered at a specific time, such as OnInit, to invoke each of the callback functions saved.

1.2.2. Container base class: Ccontainerui

With the basic control base class, we need a container to manage it, the container is Ccontainerui, which uses an array to hold all the Ccontrolui objects, and all subsequent work is based on this object.
This in Ccontainerui, the main realization of a few functions:

• Search for child controls: Ccontainerui::findcontrol
• Child control Lifecycle Management: whether to destroy (automatically destroy when remove)/delay destruction (to Cpaintmangerui to destroy together).
• Scroll bar: All the containers support scroll bar, inside it handles keyboard and mouse wheel events (Ccontainerui::D oevent), adjusts the position of all the elements inside them, and finally implements the scrolling effect when drawing
• Draw: Because there are many elements in the container, in order to speed up the container drawing, the drawing will get the area it really needs to draw, if the child control is not in this area, then it will not be drawn

And for the implementation of these controls and related to the use of further detailed further study in detail.

2. Framework Basic Process

The basic process of the framework is actually similar to the Win32 creation window process, which can be mastered very quickly if you are familiar with Win32.

intApientry WinMain (hinstance hinstance, hinstance hprevinstance, LPSTR lpCmdLine,intncmdshow)        {cpaintmanagerui::setinstance (HINSTANCE); //First step: the instance handle is associated with the render classCpaintmanagerui::setresourcepath (Cpaintmanagerui::getinstancepath () + _t ("Skin")); HRESULT Hr=:: CoInitialize (NULL);//Step two: Initialize the COM library to provide support for loading COM libraries    if(FAILED (Hr))return 0; Cmainframewnd* Pframe =NewCmainframewnd ();//Step Three: Create a window class    if(Pframe = =NULL)return 0; Pframe->create (NULL, _t ("Main program"), Ui_wndstyle_frame,0L,0,0, -, -);//Fourth step: Registering the window class with the Create window//Actually, the create operation is called here and the Win32 creates the form, and the inside actually does the following://-Registersuperclass (register a superclass that already has a window class on the base and then register a window class)//Registerwindowclass (Registration window Class)//--:: CreateWindowEx (Create window, trigger wm_create message at this time)//-Handlemessage (wm_create message processing OnCreate)Pframe->centerwindow ();//Fifth Step: Window Center display:: ShowWindow (*pframe, Sw_show); Cpaintmanagerui::messageloop (); //Sixth step: Handling Message Loops:: CoUninitialize ();//part seventh: exiting the program and releasing the COM library    return 0;}

3. Element creation mechanism

The first step: responding to wm_create messages;

The second step: the main window class is associated with the window handle;

M_PM. Init (m_hwnd)

Step three: Load XML and create interfaces dynamically, with layout interface elements

Cdialogbuilder builder;</span>Cdialogbuildercallbackex CB; </span>ccontrolui* proot =builder. Create (_t ("skin.xml"), (UINT)0,  &AMP;CB, &amp;m_pm);

Fourth step: Add controls to the hash table

Paintmanagerui::attachdialog    Initcontrols        FindControl             __findcontrolfromnamehash            pmanager->m_mnamehash.insert

Fifth step: Add notification processing

Cpaintmanagerui::addnotifier

Sixth Step: Window Drawing (above is the window creation process, through XML, all controls are loaded into Cpaintmanagerui)

Cpaintmanagerui response WM_PAINT message, start double-cached drawing m_proot,dopaint draw the background map Ccontrolui::D opaintcrenderengine The real drawing class Ppostpaintcontrol,Dopostpaint draws the control on the background map            :: BitBlt The off-screen view to the main screen

4. Message processing mechanism

First step: Register the message handler function

In the Cwindowwnd Registration window (Registerwindowclass ()), register the message callback function (__WNDPROC);

Step Two: Message distribution

The message callback function (which handles all messages sent by the system), and then the callback function distributes the message through the cmainframewnd::handlemessage of the subclass.

Non-window messages are distributed through Cmainframewnd::handlemessage call Cpaintmanagerui::messagehandler.

Step Three: Message loops

Processing the message loop in the Messageloop of the Cpaintmanagerui class;

After receiving the message, enter the message callback function (__WNDPROC);

(Note: The following is an example of a single mouse button event)

Fourth step: Handling Control messages

When the mouse is pressed (wm_lbuttondown), look for the mouse-clicked control.

Handles the mouse-down message of the control: by calling the base class Ccontrolui:: Doevent, which causes subclasses such as Cbuttonui: the:D oevent event.

The doevent of subclasses handle different types of events. Events registered by Cpaintmanagerui:: Sendnotify back to the control piece.

Duilib study Note "01"-duilib the whole frame of understanding