对TControl和TWinControl相同与不同之处的深刻理解(每一个WinControl就相当于扮演了整个Windows的窗口管理角色,主要是窗口显示和窗口大小)——TWinControl就两个作用(管理子控件的功能和调用句柄API的功能)

TControl是图形控件,它本身没有句柄,所以不能直接使用WINAPI显示,调整位置,发消息等等,只能想办法间接取得想要的效果,但是可以直接使用一些不需要句柄的API,比如InvalidateRect。
TWinControl是含有Windows句柄的窗口,它有句柄,因此所有使用句柄的WINAPI都可以直接操作它从而取得各种效果,使得Windows窗口能够被驱动从而正常的工作。所以它顺带把它的图形子控件管理起来,让它们在自己所在的一份三分地里正常的工作(我的理解:在Delphi的世界里,此时一个WinControl就相当于扮演了整个Windows的角色,用来管理它的“子窗口”控件,即TControl和TWinControl,如果说它对WinControl的管理功能还不是那么强烈和重要,但它无疑百分百的管理起了TGraphicControl,这一点非常重要)。

--------------------------------------------------------------------------

因为这个原因,TWinControl需要定义一系列的类函数,用它们包装WINAPI,使之符合Delphi的VCL整体架构,并且还更好用TControl虽然无法直接使用WINAPI驱动工作,但VCL的作者偷梁换柱使用它的父控件句柄,并使用相同的函数名称达到了相同的效果(这就是为什么李维会提到一个VCL的缺陷——TControl.Parent必须是个TWinControl,这是因为他没有意识到是Borland在有意强迫这样做,否则难道还要处处判断这个Parent是TWinControl,很可能还要多写很多异常语句,而且需要TWinControl自己的函数的时候,还要使用RTTI判断或者强行转换一下,那样岂不是麻烦死。李维大师的思路也没有错,那是一种纯面向对象理论的思路,但他本人毕竟没有深入参与VCL开发,跟Borland的大师们还有些距离,而以他的一己之力来解释整个VCL的架构与思路,而实际上估计Borland早就考虑到了这一点,对Windows编程和OO运用的如此如火纯青的人,怎么会连这一点都想不到?所以Delphi的实现方法往往已经就是理论的完美诠释,因为它对纯理论方案的一些缺陷做了最佳的弥补和平衡,而且我感觉处处都是这样,这点也是我觉得Delphi最了不起的地方。光把理论实现一遍谁不会啊,无非就是花点时间和繁琐一点。正如有朋友说的那样,C++以外的世界很精彩,不要一辈子沉迷于C++的世界,有空还是要多学几门语言并加以思考和比较一下,我就感觉自己从Delphi的一些思想和平衡性方案里受益匪浅。当然只沉迷于Delphi的世界里也是不行的,我的下一个目标是Golang和C#,哈哈哈)。这就是为什么TControl会经常有TWinControl的同名函数,因为相同名称的函数更好用嘛!比如SetBounds函数(我就是看到这个函数时想到这层意思的):

procedure TControl.SetBounds(ALeft, ATop, AWidth, AHeight: Integer);
begin
  if CheckNewSize(AWidth, AHeight) and // TControl的类函数
    ((ALeft <> FLeft) or (ATop <> FTop) or (AWidth <> FWidth) or (AHeight <> FHeight)) then
  begin
    InvalidateControl(Visible, False); // TControl的类函数,第二个参数表示暂时设置当前控件是透明的
    FLeft := ALeft;
    FTop := ATop;
    FWidth := AWidth;
    FHeight := AHeight;
    UpdateAnchorRules; // TControl的类函数,坐标和长宽设置完了,就要重新铆接一下
    // 属性设置完了,如果有API可以使之起作用就当场调用(关于显示部分,不需要句柄就有API使用,这是特殊情况)
    Invalidate; // TControl的类函数,调用TControl.InvalidateControl,再调用API声明无效区域
    // 此消息在TControl和TWinControl里都有相应的函数,图形控件使用消息再做一些自己力所能及的变化,Win控件使用消息调用类函数使之调用API真正起作用
    // 前者重新计算最大化最小化的限制和坞里的尺寸,后者使用API调整边框和控件自己的位置,当然也得重新计算最大化最小化的限制和坞里的尺寸(三明治手法) 
    Perform(WM_WINDOWPOSCHANGED, 0, 0);
    // Windows位置调整完了,还要重新对齐(本质是调用TWinControl.RequestAlign,然后调用API重新排列)
    // 但实际上是靠父Win控件重新排列自己,因为它自己没有能力拥有别的控件,当然也就不能实质上让所有控件对齐。
    RequestAlign; // TControl的虚函数,各WinControl的子类可自己改写,比如TCustomForm就改写了
    if not (csLoading in ComponentState) then Resize; // TControl的虚函数,简单调用程序员事件。子类一般不需要改写它。
  end;
end;

我们可以看到TWinControl也有相应的函数,它就可以使用API直接达到效果,它甚至还可以使用TControl定义的某些通用逻辑和效果(拜OO技术所赐):

procedure TWinControl.SetBounds(ALeft, ATop, AWidth, AHeight: Integer);
var
  WindowPlacement: TWindowPlacement; // Windows结构类型,包含最大化最小化窗口位置等6项内容
begin
  if (ALeft <> FLeft) or (ATop <> FTop) or (AWidth <> FWidth) or (AHeight <> FHeight) then
  begin
    // 如果有句柄,并且不是最小化状态,就使用API立刻调整位置
    if HandleAllocated and not IsIconic(FHandle) then // API
      SetWindowPos(FHandle, 0, ALeft, ATop, AWidth, AHeight, SWP_NOZORDER + SWP_NOACTIVATE) // API,使用完毕后Windows自己会更改WindowPlacement里的数据
    else
    // 如果还没有句柄,或者处于最小化状态下,使用API更改WindowPlacement结构的值,以备下次调用API直接显示
    begin
      // 重新设置左上角坐标以及长宽
      FLeft := ALeft; // TControl的类属性,通用属性
      FTop := ATop;
      FWidth := AWidth;
      FHeight := AHeight;
      if HandleAllocated then
      begin
        // 取得窗口的位置信息
        WindowPlacement.Length := SizeOf(WindowPlacement);
        GetWindowPlacement(FHandle, @WindowPlacement); // API
        // 更改窗口的位置信息 
        WindowPlacement.rcNormalPosition := BoundsRect; // TControl的类属性,通用属性
        SetWindowPlacement(FHandle, @WindowPlacement); // API
      end;
    end;
    // super 前面使用API设置了真实的Windows窗口属性和Delphi控件属性后,可放心大胆的调用一些函数,不是TControl已经提供了通用逻辑,就是它自己定义了一些特殊的函数,可随便使用,直接产生效果,而不再依赖别人来完成某件事情。
    UpdateAnchorRules; // TControl类函数,通用函数
    RequestAlign; // TControl类函数,通用函数
  end;
end;

TControl.GetDeviceContext这个例子也很明显,它使用父Win控件的同名函数得到DC,然后使用这个句柄调用API得到视角和增加一个新的剪裁区域,因为这两个API是和自绘有关的API,而TControl的基本设计目的之一就是显示和剪裁图形图像,因此TControl可直接使用它们实现想要的功能。

function TControl.GetDeviceContext(var WindowHandle: HWnd): HDC;
begin
  if Parent = nil then
    raise EInvalidOperation.CreateFmt(SParentRequired, [Name]);
  Result := Parent.GetDeviceContext(WindowHandle);// TWinControl的类函数,不仅仅设置DC,还从Delphi的FHandle设置参数句柄
  SetViewportOrgEx(Result, Left, Top, nil);       // API 用来改变视端口和窗口的原点,并都具有改变轴的效果,以致(0,0)不再指左上角
  IntersectClipRect(Result, 0, 0, Width, Height); // API 创建一个新的剪切区域,该区域是当前剪切区域和一个特定矩形的交集
end;

再稍微总结一下TControl的对齐过程,其实也是同理:
RequestAlign->AlignControl->DisableAlign->AlignControls(实质上干活对齐)->EnableAlign->Realign->AlignControl(nil)
整个过程的一级入口函数是:
TControl.RequestAlign;
但它只是图形控件,没有能力拥有别的控件,当然也就不能实质上让所有控件对齐,所以要执行:
TWinControl.AlignControl(AControl: TControl);
它做了整个对齐逻辑的封装,依次执行:
调用TWinControl.DisableAlign; 它执行Inc(FAlignLevel);
调用TWinControl.AlignControls(AControl: TControl; var Rect: TRect); // 所有有关控件大小、对齐、铆接的实质内容都在这里
调用TWinControl.EnableAlign; 它调用TWinControl.Realign; 它调用TWinControl.AlignControl(nil);

--------------------------------------------------------------------------

另外,TWinControl也不仅仅代表自己,一定程度上也代表了它所有的子控件。当自己发生某些变化时,可以通知自己的子控件,子控件是否愿意响应是它自己的事情,但是作为parent的义务已经尽到了,并且相互之间也做了有效的沟通。比如TWinControl.CMColorChanged就是一个不错的例子,当自己的颜色发生变化的时候,也要通知自己的所有子控件:

procedure TWinControl.CMColorChanged(var Message: TMessage);
begin
  inherited; // 自己的颜色变化起效果,是通过这句话来实现的,它包含了一连串的执行过程。父控件变化完了再通知子控件,风格很强势。
  FBrush.Color := FColor;
  NotifyControls(CM_PARENTCOLORCHANGED); // 第二个消息,组建消息并传播,通知子控件,但没有任何子控件响应
end;

再对比一下TWinControl.CMInvalidate,就会发现父控件先做变化,后通知子控件(强势);而子控件必须先通知父控件,后做变化(弱势):

procedure TWinControl.CMInvalidate(var Message: TMessage);
var
  I: Integer;
begin
  if HandleAllocated then
  begin
    if Parent <> nil then
      Parent.Perform(CM_INVALIDATE, 1, 0); // 第四个消息,递归,先通知父类(父类要提前通知)。Form1的Parent是Application,它没有响应。
    if Message.WParam = 0 then
    begin
      // API,第二个参数为NULL的话,则重画整个客户区;第三个参数TRUE则背景重绘。
      InvalidateRect(FHandle, nil, not (csOpaque in ControlStyle)); // 总算初步达到目的,使Form1失效,后面还要自绘
      { Invalidate child windows which use the parentbackground when themed }
      if ThemeServices.ThemesEnabled then
        for I := 0 to ControlCount - 1 do
          if csParentBackground in Controls[I].ControlStyle then // important
            Controls[I].Invalidate;
    end;
  end;
end;

但是无论父控件通知子控件,还是子控件通知父控件,都仅仅是通知而已,都不能强行阻止对方执行自己的变化过程(控件人格独立)。

--------------------------------------------------------------------------

TControl对TWinControl的区别和联系,主要是TControl的显示完全要依赖于TWinControl控件,主要代码在这里(红色字体):

procedure TControl.Update;
begin
  if Parent <> nil then Parent.Update; // 图形控件没法刷新自己,让父控件去刷新
end;

procedure TControl.InvalidateControl(IsVisible, IsOpaque: Boolean);
begin
  if (IsVisible or (csDesigning in ComponentState) and
    not (csNoDesignVisible in ControlStyle)) and (Parent <> nil) and
    Parent.HandleAllocated then
  begin
    Rect := BoundsRect;
    InvalidateRect(Parent.Handle, @Rect, not (IsOpaque or
      (csOpaque in Parent.ControlStyle) or BackgroundClipped));
  end;
end;

procedure TControl.Repaint;
var
  DC: HDC;
begin
  if (Visible or (csDesigning in ComponentState) and
    not (csNoDesignVisible in ControlStyle)) and (Parent <> nil) and
    Parent.HandleAllocated then
    if csOpaque in ControlStyle then
    begin
      DC := GetDC(Parent.Handle);
      try
        IntersectClipRect(DC, Left, Top, Left + Width, Top + Height);
        Parent.PaintControls(DC, Self);
      finally
        ReleaseDC(Parent.Handle, DC);
      end;
    end else
    begin
      Invalidate;
      Update;
    end;
end;

--------------------------------------------------------------------------

总结:
TControl有两个作用(通用鼠标消息和文字颜色属性功能):第一是定义所有图形控件和Win控件都要用到的通用功能(比如10个鼠标按钮消息),第二是定义所有图形控件都要用到的通用功能,比如InvalidateControl,SetColor,GetText,SetText等等,数不胜数
TWinControl两个作用(管理子控件功能和调用句柄API的功能):第一是定义Windows句柄控件所要用到的通用功能(使用API真正起作用),第二是管理其图形子控件的显示,很多时候也得管理其WinControl(如果Windows没有很好的直接管理它们的话)。

--------------------------------------------------------------------------

这里对TControl和TWinControl的同名覆盖函数总结了一下,并列个表对比它们的功能和实现手法:
http://www.cnblogs.com/findumars/p/4153769.html