谈起“消息机制”这个词,我们都会想到Windows的消息机制,系统将键盘鼠标的行为包装成一个Windows Message,然后系统主动将这些Windows Message派发给特定的窗口,实际上消息是被Post到特定窗口所在线程的消息队列,应用程序的消息循环再不断的从消息队列当中获取消息,然后再派发给特定窗口类的窗口过程来处理,在窗口过程中完成一次用户交互。
其实,WPF的底层也是基于Win32的消息系统,那么对于WPF应用程序来说,它是如何跟Win32的消息交互,这里到底存在一个什么样的机制?接下来我会通过下面几篇博文介绍这个消息机制:
WPF的消息机制(一)-让应用程序动起来
WPF的消息机制(二)-WPF内部的5个窗口
(1)隐藏消息窗口
(2)处理激活和关闭的消息的窗口和系统资源通知窗口
(3)用于UI窗口绘制的可见窗口
(4)用于用户交互的可见窗口
WPF的消息机制(三)-WPF输入事件的来源
WPF的消息机制(四)-WPF中UI的更新
谈到WPF的消息,首先应该知道DispactherObject以及Dispatcher在WPF系统中的作用。
WPF大部分的对象都是从DispatcherObject派生的,从这里派生的对象具有一个明显的特征,那就是:修改对象时所在的线程,和创建对象时所在线程必须为同一个线程,这就是微软所谓的线程亲缘性(Thread affinity)的最简单理解。那么谁能保证线程亲缘性呢?那就是Dispacher了。从DispatcherObject派生的类型继承三个重要的成员:Dispatcher属性,CheckAccess(), VerifyAccess()方法。其中后面两个方法就是检验线程亲缘性的。按照WPF的实现,如果你自己定义了个WPF的类型,并且是DispatcherObject的子类,你就必须在public的成员定义的逻辑开始处,调用base.Dispatcher.VerifyAccess(),检验线程亲缘性。那么Dispatcher到底还做了什么事情呢?
首先,我们看一下一个WPF的Application在启动之后都走了哪些逻辑:
通过调用堆栈可以看出,蓝色的部分是启动了一个线程,VisualStudio在Host的进程当中运行当前应用程序;红色的部分是从Application.Main函数开始执行,经过几个函数到达Dispatcher.Run(),最后到达Dispather.PushFrameInpl()方法。那么一个Application在Run之后,为什么要调用Dispatcher.Run()呢,他做了些什么事情你?如果通过Reflector仔细查看Application.Run(),你会发现里面实际起作用的代码并不多,最后都是Dispatcher.Run在做事情。那么一个Application启动之后,按照以前对Win32的消息机制的理解,当应用程序启动后,必须进入消息循环,对于WPF,也是一样的。那么WPF应用程序是在什么地方进入消息循环呢?其实这就是Dispatcher.Run()做的事情。查看上图最后一步Dispacther.PushFrameImpl()的代码,你会看到有下面的一段代码:
很明显,橙色的部分是一个循环,看起来是不是很眼熟,跟Win32编程碰到的消息循环是否很像?对了,这就是WPF应用程序进入了消息循环。循环调用GetMessage方法从当前线程的消息队列当中不停的获取消息,取出一个msg之后,交给TranslateAndDispatchMessage方法Dispatch到不同的窗口过程去处理。这样以来,任何需要应用程序处理的消息通过这个过程,被不同的窗口处理了,应用程序就动起来了。
ComponentOne Studio WPF 是专为桌面应用程序开发所准备的一整套控件包,崇尚优雅和创新,以“触控优先”为设计理念,内含轻量级高性能表格控件,和大量类型丰富的2D和3D图表控件,能使开发的应用程序更富创意。
下面的一篇我会介绍WPF当中的Win32窗口,正是这些窗口,处理着来自系统,或者来自应用程序内部的消息。
敬请期待~