The real difference between Twincontrol and Tcustomcontrol (Twincontrol system self-painting, Tcustomcontrol is Delphi self-painting)

The key is that Twincontrol are system self-painted, and Tcustomcontrol are all Delphi self-painted

The real difference, I think, is here:

procedureTwincontrol.wmpaint (varmessage:twmpaint);varDC, MEMDC:HDC;  Membitmap, Oldbitmap:hbitmap;  Ps:tpaintstruct; str:string;begin  //This is the first time that WM_PAINT messages are processed  //Note that this is the redraw handle control, and redrawing the graphic control is not here  //fixme Check if the DC for this message is 0 what is the parameter content of the WM_PAINT message sent by the system? Typically is the HDC handle of the current control  //draw immediately without double buffering  //fdoublebuffered is used in two places, and there is a wmerasebkgnd  if  notFdoublebufferedor(MESSAGE.DC <>0) Then  begin    //those controls that do not support self-painting and do not have graphics child controls are executed here.     //mainly refers to the Windows own control, such as Button,edit, and so on, the entire Stdctrls standard controls are not self-painted, but tform self-painted    //important7 Tcustomcontrol and Twincontrol The actual separation of the place    if  not(CscustompaintinchControlState) and(Controlcount =0) Then //Note Cscustompaint This style, that is, self-painting. Only here to judge the use.     begin      //fixme not self-painting here, it should refer to the system control?       ifSelf isTButton Then      beginStr:=Self . Name;//showmessage (str);//inherited;//strange Ah, obviously is TButton, why will fall to Tform WndProc go?      End; //Super The parent class does not have this function at all, so the message index function is called here, and if it is not found, the subclass or Twincontrol.defaulthandler is called to process the message (in fact).       //Fixme Here is super complex, execution button1.update will come here and will redraw TForm1. Experiment again, indeed. Worth writing an essay      //the last execution of CallWindowProc (Fdefwndproc) calls TButton's WndProc to process the message. Altogether 7 messages are processed separately, which turns the WM into a CN message. It will be passed to cnctlcolorbtn at last .      //http://hi.baidu.com/bakyman/item/2a426ba5c6251d37020a4d42      //Twincontrol walk here (without inheriting tcustomcontrol), such as TButton. It's going to call fixme2, it's complicated.      inherited //Fixme calls the WM_PAINT message index function of the subclass? Not quite sure .    End    //generally walk here (controls with canvas)    ElsePainthandler (Message);//Tcustomcontrol walk here, trim and redraw all child controls (send WM_PAINT messages to each)  End  Else  begin    //double buffering, preparing the memory artboard, there is no canvas at this time, so use the API old method    //Fixme not clear, in the end is with whose handle draw? DC: = GetDC (0);//parameter 0 represents the DC that gets the entire screenMembitmap: = CreateCompatibleBitmap (DC, Clientrect.right, Clientrect.bottom);//create an artboard for the current DC (presumably to keep the display in addition to the current window, as with the artboard's backplane)ReleaseDC (0, DC);//leave the Membitmap and then release the entire screen of the DCMEMDC: = CreateCompatibleDC (0);//Create a compatible DC for the current DCOldbitmap: = SelectObject (MEMDC, Membitmap);//Put the Membitmap in the MEMDC, and you'll be ready to draw in the MEMDC .    TryDC:= BeginPaint (Handle, PS);//The return value is the DC of the specified window      //Double buffering work really startsPerform (WM_ERASEBKGND, MEMDC, MEMDC);//The current control uses MEMDC to erase the background. Fixme in general, the erase background should occur before redrawingMESSAGE.DC: = MEMDC;//build a message, pass the MEMDC in, and the current control and child controls are drawn on MEMDC      //Note that this is a virtual function, and the graphical controls and CustomControl all overwrite it. CustomControl must call this parent virtual function, but the graphical control must not call it. Wmpaint (Message);//Recursive Call function (build a message, but not a message), and the DC at this time is not equal to 0, so the condition is established, into the block execution PainthandlerMESSAGE.DC: =0;//Message is used, the message parameter is reset, but all the data obtained by the message is MEMDC      //finish drawing the memory artboard, ready to switchBitBlt (DC,0,0, Clientrect.right, Clientrect.bottom, MEMDC,0,0, srccopy);//Copy the MEMDC of all controls once to the DC of the specified windowEndPaint (Handle, PS);//End Drawing Process    finallySelectObject (MEMDC, oldbitmap);//API, back to old graphicsDeleteDC (MEMDC);    DeleteObject (MEMBITMAP); End; End;End;

In addition, there are

procedureTcustomcontrol.wmpaint (varmessage:twmpaint);begin  //important Tform covers it, because there is a situation: when you minimize the drawing just draw the icon, and the normal state is not the same  //But the funny thing is, it's not about the include syntax, it's +--are these two classes not written by the same person? Include (Fcontrolstate, cscustompaint);//in standard controls, there is no place to use this tag  inherited;//because Tcustomcontrol can contain child controls, you must send a message to all child controls to redraw, and the entire calling frame is ready in Twincontrol.  //Fixme But where do you paint yourself? Exclude (Fcontrolstate, cscustompaint);End;

The real difference between Twincontrol and Tcustomcontrol (Twincontrol system self-painting, Tcustomcontrol is Delphi self-painting)