win32gui之event handling分析

win32gui之event handling分析

[email protected]

Revision: 1.0 Date: 2005/07/17

1. 前言

win32gui是一个符合C++精神的GUI框架，源自在C++届颇有声望的cuj杂志上的一系列文章，其充分发挥了C++语言的特点，有助于提高C++在GUI开发方面的框架水平。其feature很多，现列举几个：

• real GUI RAII
• no more message maps
• easy handling of events/ event handling
• thread-safety
• STL-friendly

在实际使用过程中，发现其event handling机制很独特，下面就对它进行一下分析。

2. easy handling of events

熟悉MFC，包括WTL、wxWindow开发的朋友对它们的消息映射一定不会陌生，要处理一条消息，一般需要三个步骤：

• 定义消息映射，把消息和消息处理函数关联起来。这一般是用某种形式的宏来实现的。
• 在窗口类的头文件中声明该消息处理函数。
• 在窗口类的源文件中实现该消息处理函数

 

虽然可能有wizard的帮助，这种过程仍然是繁琐的，也是有缺点的：

• 易出错。比如我想处理WM_PAINT消息，虽然我定义了ON_WM_PAINT宏，但是消息处理函数却写成了OnPaint1，这时编译器是不会 有任何错误或警告的，当然也不会调到你的这个OnPaint1函数里。换句话说，你的消息处理函数必须写得和CWnd类里定义的一模一样，如果不小心写错 了，你是不会收到任何警告的。甚至没有消息映射而只有消息处理函数，编译器也是无法发觉的。
• 看似magic的宏的大量使用，实际上减弱了代码的可读性。
• 增加、删除或修改消息映射通常会带来相应头文件的改变，从而增加编译时间。

 

win32gui是怎么做的呢？假设有一个窗口类child_view，其源文件为child_view.cpp，对其进行事件处理的步骤如下：

• 在child_view.cpp中定义一个负责事件处理的类，比如叫做child_view_hanlder：

  struct child_view_handler : event_handler<child_view_handler, child_view> {
  };                
  
              

• 直接写消息处理函数。比如要处理的消息是WM_ERASEBKGND，就这样写：

                  
  struct child_view_handler : event_handler<child_view_handler, child_view> {
      handle_event on_erase_bg(wm::draw::erase_bg_arg arg) {
          ...//some code here
          return event<WM_ERASEBKGND>().HANDLED_BY(&me::on_erase_bg);
      }
  };                    
                  注意该函数名是可以任取的。 
                  

 

这样的过程也许不比MFC等简单多少，但其优点也是突出的：

• 实现对某个消息的处理只需要一个消息处理函数，而且该消息处理函数的名称是任意的，这就大大减少了出错的机会。
• 窗口类和消息处理类是分离的，这意味改变消息处理逻辑不会影响窗口类本身。

 

至少从表面上看，这里是没有消息映射的，最后的那个return语句看起来有点像，但它在消息处理函数体里，总不会在执行消息处理函数的时候定义消息映射吧？当然也 不会是消息处理函数名称，因为它的名称是任取的。就算win32gui对Win32 GUI封装的再好，也不可能脱离win32窗口系统的原理：系统肯定会向这个 child_view窗口发送一条WM_ERASEBKGND消息，要对该消息进行处理，是一定需要该消息与消息处理函数的对应关系的，不管该关系用什么方式表达。 其实关键就是在那个return语句上，它显然可以是一种消息映射的表达，只是位置有点奇怪而已。其中的HANDLED_BY是一个宏，其定义为

#define HANDLED_BY(f) get_proxy(f).handled_by<f>()

            

先看event类模板的定义：

                        
template<int wm> struct event {
    template<class self_type>
    detail::event_keeper0<wm,self_type> get_proxy(                       handle_event (self_type::*)() ) {
        return detail::event_keeper0<wm,self_type>();
    }
    template<class self_type, class p1>

    detail::event_keeper1<wm,self_type,p1> get_proxy(                    handle_event (self_type::*)(p1) ) {
        return detail::event_keeper1<wm,self_type,p1>();
    }
    template<class self_type, class p1, class p2>
    detail::event_keeper2<wm,self_type,p1,p2> get_proxy(                 handle_event (self_type::*)(p1,p2) ) {
        return detail::event_keeper2<wm,self_type,p1,p2>();
    }
    template<class self_type, class p1, class p2, class p3>

    detail::event_keeper3<wm,self_type,p1,p2,p3> get_proxy(              handle_event (self_type::*)(p1,p2,p3) ) {
        return detail::event_keeper3<wm,self_type,p1,p2,p3>();
    }
    template<class self_type, class p1, class p2, class p3, class p4>
    detail::event_keeper4<wm,self_type,p1,p2,p3,p4> get_proxy(           handle_event (self_type::*)(p1,p2,p3,p4) ) {
        return detail::event_keeper4<wm,self_type,p1,p2,p3,p4>();
    }
    template<class self_type, class p1, class p2, class p3, class p4, class p5>

    detail::event_keeper5<wm,self_type,p1,p2,p3,p4,p5> get_proxy(        handle_event (self_type::*)(p1,p2,p3,p4,p5) ) {
        return detail::event_keeper5<wm,self_type,p1,p2,p3,p4,p5>();
    }
    template<class self_type, class p1, class p2, class p3, class p4, class p5, class p6>
    detail::event_keeper6<wm,self_type,p1,p2,p3,p4,p5,p6> get_proxy(     handle_event (self_type::*)(p1,p2,p3,p4,p5,p6) ) {
        return detail::event_keeper6<wm,self_type,p1,p2,p3,p4,p5,p6>();
    }
};
            
            

其有多个成员含函数模板，分别对应消息处理函数的参数个数从0到6的情况。这里我们的消息处理函数只需要一个参数，因此get_proxy返回的是实例属于 detail::event_keeper1类模板，再看event_keeper1的定义：

                
template<int wm, class me, class p1> struct event_keeper1 {
    template<handle_event (me::*func)(p1)> handle_event handled_by() {
        return event_adder<wm, me, func1_caller<me,p1,func> >();
    }
};
         
            

其返回的是event_adder类模板的实例：

                
template<int wm, class me, class func> struct event_adder : handle_event {
    event_adder() {
        if ( detail::initialize_static_trick() ) {
            assert(false); // should never happen
            s_adder = event_adder_impl<wm,me,func>();
        }
    }
    static event_adder_impl<wm,me,func> s_adder;
};

            

可以看到，event_adder的构造函数好像也没做什么，关键在于s_adder这个static成员上，看看其类型定义：

                

template<int wm, class me, class func> struct event_adder_impl : register_possible_dialog<me> {
    typedef typename func::first_arg first_arg;

    event_adder_impl() {
        WIN32GUI_LOG("adding event " << wm << " for " << typeid(me).name());
        if ( initialize_static_trick() ) {
            // force the compiler to generate the constructor for the 'me' class
            new me;
            // v1.5+
            // extra safety for the first argument...
            typedef typename ignore_enhanced_msg<first_arg>::arg func_first_arg;
            int first_argument_and_return_DONOT_match_please_check_again = check_event<wm,func_first_arg>( (func_first_arg*)0);
        }
        // note: for the same message, we might have multiple functions
        me::s_events()[ (UINT)wm].push_back( &func::call );        
    }
};

            

真相大白了！最后一句清楚地表明，这里是有消息映射的！实际上win32gui对于每个event handler类型，在内部都为其维护了一个消息映射表，使用的数据结构是stl::map。消息处理函数的return语句在运行时实际什么也没做，它的存在只是为了让编译器产生event_adder_impl的静态变量，在这些 静态变量的初始化时刻，其构造函数被调用，从而建立消息映射关系。

3. 结束语

虽然win32gui号称no more message maps，但从上分析，其还是存在消息映射的，这也是由win32窗口系统本身决定的；只不过其表达方式有些特别，利用了模板和静态变量技术，较之MFC之类的方式，其优点也是相当明显的。