基于事件驱动编程

所谓事件驱动，简单地说就是你点什么按钮（即产生什么事件），电脑执行什么操作（即调用什么函数）.当然事件不仅限于用户的操作. 事件驱动的核心自然是事件。从事件角度说，事件驱动程序的基本结构是由一个事件收集器、一个事件发送器和一个事件处理器组成。事件收集器专门负责收集所有事件，包括来自用户的（如鼠标、键盘事件等）、来自硬件的（如时钟事件等）和来自软件的（如操作系统、应用程序本身等）。事件发送器负责将收集器收集到的事件分发到目标对象中。事件处理器做具体的事件响应工作，它往往要到实现阶段才完全确定，因而需要运用虚函数机制（函数名往往取为类似于HandleMsg的一个名字）。对于框架的使用者来说，他们唯一能够看到的是事件处理器。这也是他们所关心的内容。

视图（即我们通常所说的“窗口”）是“事件驱动”应用程序的另一个要元。它是我们所说的事件发送器的目标对象。视图接受事件并能够对其进行处理。当我们将事件发送到具体的视图时，实际上我们完成了一个根本性的变化：从传统的流线型程序结构到事件触发方式的转变。这样应用程序具备相当的柔性，可以应付种种离散的、随机的事件。

由于Windows本身是基于“事件驱动”模型的。因而在Windows操作系统下实现应用程序框架有相当的便利。在事件驱动程序的基本单元中，事件收集器已经由Windows系统完成；事件发送器也已经由Windows完成了部分内容。之所以是部分而非完全是因为Windows是用C语言实现的，而不是C++。由于没有对象，Windows将事件发送到所谓的“窗口函数”中（尽管不是发送到具体的对象，但应该说这是面向对象方式实现的一个变体）。要感谢Windows做了这件事。确定事件的目标所要做的工作的复杂可能要超出我们的想象。weWidgets的中所有可以处理事件的类都继承自wxEvtHandler，其中包含frames,buttons,menus,even documents，所有的窗体类（即从wxWindow继承的类）和程序类（application class).

这些类可以有一个事件表，用来绑定事件和被调用的函数（handler functions).

过程3.2. 建立一个静态事件表（即编译时生成的事件表）的操作步骤

建立一个新类（直接或间接从wxEvtHandler继承）

为每个要处理的事件声明被调用的函数

在被处理的事件所在的类的声明中加入宏DECLARE_EVENT_TABLE

在宏BEGIN_EVENT_TABLE... END_EVENT_TABLE（就是事件表）中将函数与枚举的数字绑定（因为产生该类型的事件的按钮不唯一，要用枚举数来区分）；有些事件不必与枚举数绑定，因为产生该类型的事件的对象可以确定（比如就是this).

1.要理解事件驱动和程序，就需要与非事件驱动的程序进行比较。实际上，现代的程序大多是事件驱动的，比如多线程的程序，肯定是事件驱动的。早期则存在许多非事件驱动的程序，这样的程序，在需要等待某个条件触发时，会不断地检查这个条件，直到条件满足，这是很浪费cpu时间的。而事件驱动的程序，则有机会释放cpu从而进入睡眠态（注意是有机会，当然程序也可自行决定不释放cpu），当事件触发时被操作系统唤醒，这样就能更加有效地使用cpu.

2.再说什么是事件驱动的程序。一个典型的事件驱动的程序，就是一个死循环，并以一个线程的形式存在，这个死循环包括两个部分，第一个部分是按照一定的条件接收并选择一个要处理的事件，第二个部分就是事件的处理过程。程序的执行过程就是选择事件和处理事件，而当没有任何事件触发时，程序会因查询事件队列失败而进入睡眠状态，从而释放cpu。

3.事件驱动的程序，必定会直接或者间接拥有一个事件队列，用于存储未能及时处理的事件。

4.事件驱动的程序的行为，完全受外部输入的事件控制，所以，事件驱动的系统中，存在大量这种程序，并以事件作为主要的通信方式。

5.事件驱动的程序，还有一个最大的好处，就是可以按照一定的顺序处理队列中的事件，而这个顺序则是由事件的触发顺序决定的，这一特性往往被用于保证某些过程的原子化。

6.目前windows,linux,nucleus,vxworks都是事件驱动的，只有一些单片机可能是非事件驱动的。

都是手工敲的，很辛苦的。另外，我推荐你看一下维基百科，讲得很清楚，很透彻，直达本质。