• wtl学习总结


    在windows平台,相比MFC,我更喜欢WTL,因其简洁漂亮。所以陆续花了一年的时间学习之,这里总结一下(在学习Wtl/Atl之前,最好是对WinApi编程有一定的了解)。

    安装

            Wtl主页 http://sourceforge.net/projects/wtl/ ,整个库就是一堆.h文件,官方没有提供Installer,下载后解压到某个目录即可。

            如果需要在VS中使用“工作导向”,可以点击Appwiz目录下的对应js文件来安装之。虽然没有直接对VS2010的支持,不过拿VS2008的改改即可,详情Google下。

            为了在VS中使用Wtl,可以将include目录添加到全局Include Path。不过如果仅仅希望对单个项目有效,则在添加C++ Include Path的同时,可能还需要添加资源的Include Path。如果不希望以来第三方的库,可以直接将源码放在项目内。

     

    Atl

            学习Wtl,不可能跳过Atl,Wtl底层就是使用Atl。关于Atl这里就几个点讲一下:

    1. ATL-style 模板
    2. 窗口创建和初始化
    3. Thunk技术
    4. 回调和消息绑定

     

    ATL-style 模板

     
    template <class T>
    class B1
    {
    public:
        void SayHi()
        {
            T* pT = static_cast<T*>(this);   
    
            pT->PrintClassName();
        }
    protected:
        void PrintClassName() { cout << "This is B1"; }
    };
    
    class D1 : public B1<D1>
    {
        // No overridden functions at all
    };

     

    使用这个模板形式有几个好处:

    1. 不需要使用指向对象的指针。
    2. 节省内存,因为不需要虚函数表。
    3. 因为没有虚函数表所以不会发生在运行时调用空指针指向的虚函数。
    4. 所有的函数调用在编译时确定(译者加:区别于C++的虚函数机制使用的动态编连),有利于编译程序对代码的优化。

    http://www.winmsg.com/wtl/Part1.htm

     

    窗口创建和初始化

            有个哥们就这个流程分析了一下,地址在这里 http://blog.csdn.net/jznsmail/archive/2004/12/01/200947.aspx 。

            在Windows下,任何窗口创建都是通过CreateWindowEx或者CreateWindow函数来实现之,Wtl/Atl也不例外,(不过WtlAtl的流程略有不同)。详细的流程见上面链接,这里就几个重点说一下(不仅仅是Atl,也包括Wtl的内容)

            对于Windows窗口,需要派生自CFrameWindowImpl类,创建和初始化窗口就在该类的CreateEx函数实现。通过前面讲到的“ATL-style 模板”,CreateEx会调用Create函数,CFrameWindowImpl提供了默认的Create实现,不过也可以在派生类中定制。在CFrameWindowImpl类成员函数Create中会首先注册窗口,然后才创建之。

            在CFrameWindowImpl的Create函数中会通过CFrameWindowImplBase的成员函数Create创建实际的窗口,使用API函数CreateWindowEx。

            在CFrameWindowImpl的Create函数中会调用CFrameWndClassInfo类成员函数Register注册窗口,注册用到的信息通过DECLARE_FRAME_WND_CLASS或DECLARE_FRAME_WND_CLASS_EX宏来指定。在这两个宏中会指定静态成员函数StartWindowProc 作为窗口回调。这个静态成员在CWindowImplBaseT类中定义。在这个静态成员中使用了下面提到的Thunk技术动态地修改回调参数,同时将回调重置为该类的另一个静态成员WindowProc(见API函数SetWindowLongPtr和属性GWLP_WNDPROC

            以上提到的是Wtl流程的一个简单概述,对于普通窗口(控件),我们一般使用Atl的那一套而非Wtl。

            对于控件,一般派生自CWindowImpl窗口,窗口工作在该类的成员函数Create中完成。注册窗口的信息使用DECLARE_WND_CLASS或DECLARE_WND_CLASS_EX宏。具体的注册操作在ATL::CWndClassInfo类的成员函数Register中完成,窗口的创建在CWindowImplBaseT类的成员函数Create中完成。

     

    Thunk技术

            对于Windows API,从系统的消息回调出来的消息唯一的标识符就是HWND句柄,而当前随便一个UI程序都有相当之多的控件,所以必须要有一种行之有效的方法来通过这个句柄定位控件。比较傻B的方法就是建立一个HWND到控件类实例的映射,然后在消息收到后查询之,不过这种方法有很大的局限性。

            Atl用Thunk技术来处理这个问题,这个所谓的“Thunk技术”干的事挺简单,不过要理解代码还真不容易(至少我是花了不少功夫)。有兴趣可以研究下代码:

    (Microsoft Visual Studio 9.0VCatlmfcincludeatlstdthunk.h)

    #pragma pack(push,1)
    struct _stdcallthunk
    {
    	DWORD   m_mov;          // mov dword ptr [esp+0x4], pThis (esp+0x4 is hWnd)
    	DWORD   m_this;         //
    	BYTE    m_jmp;          // jmp WndProc
    	DWORD   m_relproc;      // relative jmp
    	BOOL Init(DWORD_PTR proc, void* pThis)
    	{
    		m_mov = 0x042444C7;  //C7 44 24 0C
    		m_this = PtrToUlong(pThis);
    		m_jmp = 0xe9;
    		m_relproc = DWORD((INT_PTR)proc - ((INT_PTR)this+sizeof(_stdcallthunk)));
    		// write block from data cache and
    		//  flush from instruction cache
    		FlushInstructionCache(GetCurrentProcess(), this, sizeof(_stdcallthunk));
    		return TRUE;
    	}
    	//some thunks will dynamically allocate the memory for the code
    	void* GetCodeAddress()
    	{
    		return this;
    	}
    	void* operator new(size_t)
    	{
            return __AllocStdCallThunk();
        }
        void operator delete(void* pThunk)
        {
            __FreeStdCallThunk(pThunk);
        }
    };
    #pragma pack(pop)

     

            这里我就不说什么原理了,我这水平也说不清:-)。

            Thunk技术实际上就是用一段汇编代码将函数的参数动态的替换,具体来说是将回调函数参数HWND动态替换成窗口类实例的指针。关于它推荐阅读 http://www.cngr.cn/article/54/395/2006/2006071928301.shtml 。

            这个过程在CWindowImplBaseT类的静态成员StartWindowProc中实现。首先在注册窗口时会指定它为回调,当第一次调用时,通过Thunk技术动态地修改回调参数,同时将回调重置为该类的另一个静态成员WindowProc。具体的实现代码如下:

    pThis->m_thunk.Init(pThis->GetWindowProc(), pThis);
    WNDPROC pProc = pThis->m_thunk.GetWNDPROC();
    WNDPROC pOldProc = (WNDPROC)::SetWindowLongPtr(hWnd, GWLP_WNDPROC, (LONG_PTR)pProc);

     

            那这个类实例在哪获取呢?其实Wtl/Atl实现也并不美观,通过CAtlWinModule类存储这些指针,很显然整个程序只应该包含一个CAtlWinModule类实例,这也是为什么我们经常看到这个实例前带一个extern关键字。

            在新的回调WindowProc中,Atl将参数HWND转型为CWindowImplBaseT类指针,然后调用该类的成员函数ProcessWindowMessage来进一步派发消息。这个函数怎么定义看下一节内容。

     

    回调和消息绑定

            前面提到一个ProcessWindowMessage函数,它最初在CMessageMap类中以纯虚函数的形式定义。在Atl中不管什么类,只要派生自CMessageMap就可以处理消息,这就提供了很大的灵活性。

            ATL定义了一堆预处理宏来实现这个函数和分发逻辑,典型的如下:

    	BEGIN_MSG_MAP(CMyWindow)
    		MESSAGE_HANDLER(WM_CLOSE, OnClose)
    		MESSAGE_HANDLER(WM_DESTROY, OnDestroy)
    		COMMAND_ID_HANDLER(IDC_ABOUT, OnAbout)
    	END_MSG_MAP()

            前后两个宏用于定义ProcessWindowMessage函数,中间则通过一个Switch结构来定义分发逻辑和回调绑定。

            ATL这一套结构有几个好处:

    1. 避免过多的纯虚函数导致额外的开销
    2. 容易将消息处理重定向,例如将消息处理重定向到一个非窗口类,实现UI和逻辑分离。也可以让同一个消息处理类同时处理多个窗口的消息。具体见ATL定义的那堆宏。

            Wtl在Atl基础上针对特定消息定义了很多更加精确的宏,不过个人不是很喜欢,因为懒得去记。

     

    Wtl入门

            最基本的Wtl程序可以通过Appwiz来生成,很有必要理解下Wtl程序的流程。简单地讲,控件使用CButton等封装类(atlctrls.h),窗口使用CFrameWindowImpl派生。如果希望自定义控件,可以派生自CWindowImpl(自绘还需要继承其他自绘支持类,见后面说明),例如

    class CBeepButton: public CWindowImpl< CBeepButton,CButton >
    {
    public:
    	DECLARE_WND_CLASS( _T("CBeepButton"))
    	BEGIN_MSG_MAP( CBeepButton )
    	END_MSG_MAP()
    };

            不过上面的类封装除了装逼没有任何用处!

            发现几个比较恶心的地方提一下。

            如果在自定义控件有绘制字体时,绘出来的字很奇怪,和默认的字体相差较大,后来发现可以手动设置字体将其设置为UI默认字体。

    	m_widget_->SetFont(AtlGetStockFont(DEFAULT_GUI_FONT));

            对于动态创建的Edit或者RichEdit,边框都很奇怪,为了设置默认的边框,需要

    	m_widget_->ModifyStyleEx(0, WS_EX_CLIENTEDGE, SWP_DRAWFRAME);

     

    超类化

            超类化(superclass )是一种生成新的窗口类的方法。它的中心思想是依靠现有的窗口类,克隆出另一个窗口类。被克隆的类可以是Windows预定义的窗口类,这些预定义的窗口类有按钮或下拉框控制等等。也可以是一般的类。克隆的窗口类使用被克隆的类(基类)的窗口消息处理函数。

            克隆类可以有自己的窗口消息处理函数,也可以使用基类的窗口处理函数。

    http://www.builder.com.cn/2007/1116/637833.shtml )

            超类化是以类型为单位来设置,也就是被超类的类必须是已经存在的窗口(很显然,如果想“超”自定义窗口类,必须保证该类至少被用过一次或者手动注册过,如果没注册则超类会初始化失败)。在消息处理时,Wtl首先会使用超类的处理函数,如果没处理,则会调用“被超类”的消息处理函数来处理。

            那这个“被超类”的消息处理函数在哪里呢?毕竟每次只能注册一个回调函数。实际上在CWindowImplBaseT类中包含一个成员m_pfnSuperWindowProc用于在超类化时存储“被超类”的原始回调。这个成员在CFrameWndClassInfo类或_ATL_WNDCLASSINFOW结构的成员函数Register调用时作为参数传入实现初始化。

            通过宏DECLARE_FRAME_WND_SUPERCLASS或DECLARE_WND_SUPERCLASS来声明一个超类,两者原理都是一致的,即定义一个OrigWndClassName。在注册窗口类是首先获得OrigWndClassName类的注册信息,然后替换回调,并且将原来的回调保存在参数中,这个参数即前面提到的m_pfnSuperWindowProc。

            关于这两回调的配合,可以参考CWindowImplBaseT类静态成员函数WindowProc(这个函数即通过Thunk技术重置后的回调函数,见前面说明)。Wtl首先会调用当前的回调,如果返回FALSE,则继续调用原来的回调。

            为了测试超类化自定义窗口类,我写了如下代码:

    class CBeepButton1: public CWindowImpl< CBeepButton1,CButton >
    {
    public:
    	DECLARE_WND_CLASS( _T("CBeepButton1"))
    	BEGIN_MSG_MAP( CBeepButton1 )
    		MESSAGE_HANDLER( WM_LBUTTONDOWN, OnLButtonDown )
    		MESSAGE_HANDLER( WM_LBUTTONUP, OnLButtonUp )
    	END_MSG_MAP()
    
    	LRESULT OnLButtonDown( UINT, WPARAM, LPARAM, BOOL& bHandled )
    	{
    		this->SetWindowText("Press");
    		bHandled = FALSE; // alternatively: DefWindowProc()
    		return 0;
    	}
    
    	LRESULT OnLButtonUp( UINT, WPARAM, LPARAM, BOOL& bHandled )
    	{
    		this->SetWindowText("Release");
    		bHandled = FALSE; // alternatively: DefWindowProc()
    		return 0;
    	}
    };
    
    class CBeepButton: public CWindowImpl< CBeepButton >
    {
    public:
    	DECLARE_WND_SUPERCLASS( _T("BeepButton"), _T("CBeepButton1") )
    	BEGIN_MSG_MAP( CBeepButton )
    		MESSAGE_HANDLER( WM_LBUTTONDOWN, OnLButtonDown )
    	END_MSG_MAP()
    	LRESULT OnLButtonDown( UINT, WPARAM, LPARAM, BOOL& bHandled )
    	{
    		bHandled = FALSE; // alternatively: DefWindowProc()
    		return 0;
    	}
    };

            经测试发现几个问题,为了使用 CBeepButton,必须先实现一个 CBeepButton1(目的是为了注册窗口类,主要是手动注册不方便)。否则 CBeepButton1会注册失败。即便如此 CbeepButton还是无法运行,究其原因是因为Thunk技术未能重置回调。

            前面说过,Atl在初始化一个窗口类时,会使用Thunk技术动态重置回调。这个两个回调分别是CWindowImplBaseT类静态成员函数StartWindowProc和WindowPro,Thunk技术在前者中被使用,是一个临时的回调,具体的消息分发在后者进行。

            当超类化一个自定义窗口类时,首先会获得原窗口的回调,而这个回调很显然是StartWindowProc,而新的窗口类并非处理了所有消息,所以总是有部分消息会发送到原窗口类的回调,即StartWindowProc。杯具就在这里,StartWindowProc是一个临时的回调。实际中当消息派发到这里时会碰到断点,因为无法从CAtlWinModule中获得类实例的指针(这都不是该窗口类初始化过程,当然找不到了)。这不得不说是Wtl的一个Bug,不过就目前这种框架,要改好还真不容易。

     

    子类化

            子类化(subclass)是普遍采用的一种扩展窗口功能的方法。它的大致原理如下。

            在一个窗口创建完了之后,将该窗口的窗口函数替换成新的窗口消息处理函数。这个新的窗口函数可以对某些需要处理的特定的消息进行处理,然后再将处理传给原来的窗口函数。

            注意它与superclass的区别。

            Superclass是以一个类为原版,进行克隆。既在注册新的窗口类时,使用的是基类窗口的窗口函数。

            而subclass是在某一个窗口注册并创建后,通过修改该窗口的窗口消息函数的地址而实现的。它是针对窗口实例。

    http://www.builder.com.cn/2007/1116/637833.shtml )

            子类化的核心就是前面提到的Thunk技术,这里就不废话了。

     

    自绘

            说的自绘,我真想吐血,很不明白微软为什么要为了自绘搞出那么一套鸟毛东西,虽然所有的自绘都可以通过Paint来完成,不过既然微软推出那么一套鸟毛,总是会要犹豫一下,”我用Paint来做会不会有什么不妥“。

            并不是所有的内置控件都支持那一套鸟毛的自绘,Wtl通过COwnerDraw类和CCustomDraw 类来简化这一套东西的开发,其实就是定义一堆宏来处理回调,提供一个相对简单的接口给程序员。为了能够让控件收到这些自定义消息,需要在父窗口加入反射宏DEFAULT_REFLECTION_HANDLER()。

            不过个人很少用这东西,即便要自绘Button,我也是通过WM_PAINT来做的(这种做法有什么不妥忘各位指出,不过我没发现效率有多低,至少结构一致和美观,我想谁都不想去理解那么多规则,简单就是美)。

     

    浏览器控件

            如今越来越多的UI程序选择浏览器控件来显示网页内容,这有很多好处,至少简化了开发并且可以实现很复杂的样式,更重要的是无需升级可保持最新。

            Wtl官方并没有内置浏览器控件,不过可以参考这里http://devel.openocr.org/svn/openocr/trunk/cuneiform/interface/icrashreport/wtl/samples/tabbrowser/browserview.h , 

    ----------------------------------------------WTL 方式对话框数据交换(DDX)

    WTL 学习笔记 -- DDX 和 DDV

     MFC程序员的WTL指南: Part IV - 对话框与控件(二)

    http://www.cnblogs.com/procoder/archive/2009/06/11/1501044.html

    ---wtl 界面开发 http://blog.163.com/l1_jun/blog/static/14386388201052922725417/

  • 相关阅读:
    echarts 点击事件 点击一次触发多次
    echarts 没有数据时,无数据展示
    递归 出现的一些问题
    echarts 下钻 返回设成按钮的样式
    阻止冒泡 阻止默认事件
    前端如何绘制svg格式图片
    html头部的标签有哪些?
    ant design 封装可填写Tag标签的input框
    React:通过Vite集成Tailwind CSS
    React:通过vite批量导入图片
  • 原文地址:https://www.cnblogs.com/wliangde/p/4259281.html
Copyright © 2020-2023  润新知