ch1Win32基本程序观念.pptVIP

Ch1:Win32基本程序观念 内容提要 Win32程序开发流程 以消息为基础,以事件驱动之 一个具体而微的Win32程序 Console程序及其与DOS程序的差别 实例介绍 Win32程序开发流程 以消息为基础,以事件驱动之 一个具体而微的Win32程序 程序进入点WinMain 窗口类之注册与窗口之诞生 消息循环 窗口的生命中枢:窗口函数 消息映射(Message Map)的雏形 模块定义文件(.DEF) 资源描述文件(.RC) Windows程序的生与死 空闲时间的处理:OnIdle 程序进入点WinMain WinMain则是Windows程序的进入点: Main是一般C程序的进入点: 当Windows的”外壳”(shell,例如Windows的文件管理器或资源管理器)侦测到用户欲执行一个Windows程序,于是调用加载器把该程序加载,然后调用C starup code,后者再调用WinMain,开始执行程序.WinMain的四个参数由操作系统传进来 窗口类之注册与窗口之诞生 注册窗口-RegisterClass设定窗口属性(外貌和行为) 创建窗口-CreateWindow 显示窗口-ShowWindow 消息循环 初始化工作完成后，WinMain进入所谓的消息循环： While(GetMessage(msg,..)){ TranslateMessage(msg);//转换键盘消息 DispatchMessage(msg);}//分派消息 DispatchMessage会将消息传给窗口函数去处理。没有指定函数名称，却可以将消息传送过去，岂不是很玄？这是因为消息发生之时，操作系统已根据当时状态，为它标明了所属窗口，而窗口所属的窗口类又已经明白标示了窗口函数，所以DispatchMessage自有脉络可寻。 消息循环中的GetMessage是Windows 3.x系统非强制性（non-preemptive）多任务的关键。应用程序籍由此操作，提供了释放控制权的机会：如果消息队列上没有属于我的消息，我 就把机会让给别人。通过程序之间彼此协调让步的方式，达到多任务能力。Windows 9x和Windows NT具备强制性多任务能力，不再非靠GetMessage释放CPU控制权不可，但程序写法依然不变，因为应用程序仍然需要靠消息推动。 窗口的生命中枢:窗口函数 消息循环中的DispatchMessage把消息分配到哪里呢？它通过USER模块的协助,送到该窗口的窗口函数去了。窗口函数通常利用switch/case方式判断消息种类，以决定处理方式。由于它是被Windows系统所调用（我们并没有在应用程序的任何地方调用此函数），所以这是一种call back函数，意思是指“在你的程序中，被Windows系统调用的函数，这些函数由你设计，但是永远不会也不该被你调用，它们是为Windows系统准备的。 在程序进行过程中，消息由输入装置，经由消息循环的抓取，源源传送给窗口并进而送到窗口函数中去。窗口函数的形式： LRESULT CALLBACK WndProc(HWND hWnd,UINT message,WPARAM wParam,LPARAM lParam) 注意，不论什么消息，都必须被处理，所以switch/case指令中的default:处必须调用DefWindowProc,这是Windows内部默认的消息处理函数。 我想很多人都会问这个问题：为什么Windows Programming Modal要把窗口函数设计为一个call back函数？为什么不让程序在抓到消息（GetMessage）之后直接调用它？原因是，除了你需要调用它，有很多时候操作系统也要调用你的窗口函数（例如当某个消息产生或某个事件发生）。窗口函数设计为callback形式，才能开放出一个接口给系统调用 消息映射(Message Map)的雏形（1） 首先定义一个MSGMAP_ENTRY结构和一个dim宏： 请注意MSGMAP_ENTRY的第二个元素pfn是一个函数指针，该指针所指的函数处理nMessage消息。这正是面向对象观念中把“数据”和“处理数据的方法”封装起来的一种具体实现 消息映射(Message Map)的雏形（2） 接下来，组织两个数组_messageEntries[ ]和_commandEntries[ ],把程序中欲处理的消息以及消息处理例程的关联性建立起来 消息映射(Message Map)的雏形（3） 于是窗口函数可以这么设计： OnCommand函数可以这么设计： 消息映射(Message Map)的雏形（4） 这么一来，WndProc和OnCommand永远不必改变，每当有新的要处理的消息，只要在_messageEntri