Programming Microsoft Windows CE .NET.doc

Transcription

1 Programming Microsoft Windows CE.NET, Third Edition by Douglas Boling Microsoft Press 2003 (1224 pages) ISBN: 作者对如何把 Windows 嵌入式程序设计经验应用到 Windows CE.NET 环境里做了娴熟的示范 这这个环境里, 可以为支持 Windows 的 Pocket PC Smartphone 以及其它下一代设备编写更快, 更小的应用 目录前言第一部分 - Windows 程序设计基础第 1 章 - "Hello Windows CE" 第 2 章 - 屏幕绘画第 3 章 - 输入 : 键盘 鼠标和触摸屏第 4 章 - 窗口 控件和菜单第 5 章 - 公共控件和 Windows CE 第 6 章 - 对话狂和属性表第二部分 - Windows CE 程序设计第 7 章 - 内存管理第 8 章 - 文件和注册第 9 章 - Windows CE 数据库第 10 章 - 模块 进程和线程第 11 章 - 通知机制第三部分 - 通信第 12 章 - 串口通信第 13 章 - Windows CE 网络通信第 14 章 - 设备间通信第 15 章 - 桌面连接第四部分设备编程第 16 章 - 浏览器 Shell 编程第 17 章 - Pocket PC 编程第 18 章 - Pocket PC 扩展第 19 章 - Smartphone 编程第 20 章 - 游戏 API-GAPI 第五部分 - Windows CE 高级编程第 21 章 - 系统编程第 22 章 - 设备驱动程序和服务编程第 23 章 -.Net CF 下的程序设计索引 封底 用这本广受业界推崇的 Windows CE.NET 参考书, 为最新的智能移动设备设计整洁 高性能的 应用程序 在第 3 版里, 基本内容已经根据 Windows CE.NET 4.2 和微软.NET CF 做了更新 作者 Douglas Boling 对如何把 Windows 嵌入式程序设计经验应用到 Windows CE.NET 环 境里做了娴熟的示范 在这个环境里, 可以为支持 Windows 的 Pocket PC Smartphone 以

2 及其它下一代设备编写更快, 更小的应用 在 Douglas Boling 专家级的指导下, 可以促进提 升你的技术, 更快的适应市场变化 内容要点 : 用特定的技术处理内存 存储和电源限制 能够和网络 PC 其他设备( 包括使用红外线和蓝牙技术的设备 ) 通信 新内容 -- 为 Smartphone 的特殊要求编程, 包括安全特性 新内容 -- 在 Pocket PC Phone 和 Smartphone 上使用短消息服务 (SMS) 写面向连接的应用 新内容 -- 编写自己的设备驱动程序 服务程序和超级服务程序 配置用户和事件通知 使用游戏 API 编程 关于作者 作为一个作家 培训师和顾问,Douglas Boling 从 Windows CE 初始就开始涉足这个领域了, 被公认为这个平台的权威 他频繁的出现在各种主要的专业开发人员大会上, 微软嵌入式开发大会 微软专业开发者大会以及 TechEd 都有他的身影 通过他的 Boling Consulting 公司,Doug 为许多在 Windows CE 上工作的一流公司做教学和咨询 主要的专业开发人员大会上, 微软嵌入式开发大会 微软专业开发者大会以及 TechEd 都有他的身影 通过他的 Boling Consulting 公司,Doug 为许多在 Windows CE 上工作的一流公司做教学和咨询 前言 几乎是从 Windows CE 诞生起, 我就开始在它上面工作了 作为一个多年的 Windows 程序员, 能够将我的 Windows 程序设计经验应用到如此多的不同而又很小的系统上, 使我感到吃惊 这些 Windows CE 系统运行在各个领域, 从类似 PC 的迷你膝上机到蜂窝手机, 再到深藏于一些大型工业设备里的嵌入式设备 Windows CE 里的 Win32 API 使成千上万的 Windows 程序员能够在一个全新的系统领域里写应用程序 然而, 细微的差别, 使得在 Windows CE 中编程不同于在桌面版本的 Windows 中编程 我将在本书里进行讲解的正是这些差异 Windows CE 到底是什么? Windows CE 是最小, 也可能是最有趣的微软 Windows 操作系统 Windows CE 彻头彻尾的被设计成一个基于 ROM 的, 使用 Win32 API 子集的小型操作系统 Windows CE 把 Windows API 扩展到那些不支持大容量 XP 内核的领域和机器上 目前逐步消亡的 Windows 95/98/Me 对那些需要向后兼容 MS-DOS Windows 2.x 和 3.x 程序的用户来说, 是个大操作系统 虽然它有缺点, 但 Windows Me 还是继承了这个困难的任务 另一方面,Windows NT/2000/XP 是用于企业级的 它牺牲了兼容性和大小, 来达到高级别的稳定和健壮 Windows XP 家庭版是 Windows XP 的一个版本, 用于家庭用户, 它尽力保持了兼容性, 但这相对于它的基本目标 -- 稳定性来说, 兼容性还是排在第 2 位的

3 Windows CE 并不向后兼容 MS-DOS 或者 Windows. 它不是一个为企业级计算设计的全功能的操作系统 相反,Windows CE 是一个轻量级 多线程的操作系统, 它具有可选的图形用户接口 它的长处在于它的小尺寸 Win32 API 子集和多平台支持 Windows CE 也是最初.NET CF 版本的基础,.NET CF 是.NET 在移动和嵌入式设备上的版本 这个精简框架使用一个更小的类库提供了一个同样强大的.NET 运行时环境, 这使得它适合用于电池供电的小型设备上 Win CE 历史简介 为了理解 Windows CE 的历史, 你需要理解操作系统和使用操作系统的产品之间的区别 操作系统是微软内部一组核心团队开发的 他们的产品就是操作系统自身 其他团队, 比如开发 Pocket PC 的团队, 在操作系统即将发布的时候, 获得并使用最新版本的操作系统 这种划分成两部分的方式, 可能对理解 Windows CE 是怎么发展的会产生一些混淆 下面让我们分别看一下这两部分的历史 -- 设备和操作系统自身 设备首批为 Windows CE 设计的是手持式 管理器 设备, 配有 480*240 或 640*240 的屏幕和 Chiclet 键盘 ( 计算机常用的一种键盘, 有一个很小的矩形键盘 ) 这些设备, 称为手持式 PC, 在 1996 年首次面世 在 Fall Comdex 97 大会上,Windows CE 2.0, 一个进行了显著更新的操作系统版本发布了, 和它配套的是类似的更新一些的硬件, 具有 640*240 的横向屏幕, 一些是彩色的, 还具有略大一些的键盘 1998 年 1 月, 消费电子展览会上, 微软宣布了两个平台, 掌上电脑 ( 译者注 :Palm-size PC 可以看作 Pocket PC 的前身, 其中使用 Windows CE 2.x 的称为 Palm-size PC, 使用 Windows CE 3.x 的称为 Pocket PC) 和车载 PC( 译者注 :Auto PC 是 Windows CE 的一种应用模式, 多用在一些车载电脑 工业自动控制等场合, 可按客户需要修改输入输出方式而不限定使用原有的程序 ) 掌上电脑目标直接瞄准了由 Palm 0s 统治的基于笔式的管理器市场 掌上电脑具有纵向显示的特点, 并配有 240*320 的屏幕, 使用输入笔来作为输入方式 但是很不幸, 对 Windows CE 爱好者来说, 对这种原始掌上电脑, 公众显然缺乏热情 此后, 出现了一种新的迷你膝上式 Windows CE 设备, 配备了触摸式输入键盘和 VGA/Super VGA 屏幕 这种设备被称为 H/PC( 专业版 ), 电池可使用 10 小时, 并配备了微软 Pocket Office 软件改进版 这种设备中有许多具有内置 Modem, 一些甚至配备了 thenstandard 屏幕, 移动轨迹垫或者 IBM 轨迹球设备 2000 年 4 月, 微软宣布了 Pocket PC, 它对老式掌上电脑 (Palm-size PC) 做了极大的增强 最初的 Pocket PC 使用预发布的具有更多功能的 Windows CE 3.0 Pocket PC 的用户界面也有所不同, 具有更加整洁的 2 纬外观和修改过的主页 -Today 桌面 然而,Pocket PC 最重要的特性是极大的改进了 Windows CE 的性能 微软做了很多工作来调优 Windows CE 的性能 这些改进加上更快的 CPU, 可以让系统像 Pocket 管理器期望的那样运行的更快 在这种 Pocket PC 里, 摩尔定律使得 Windows CE 设备可以跨越这条线 : 现在硬件已经有能力提供 Windows CE 需要的运算能力了 手持式 PC 在 2000 年时升级到了 Windows CE 3.0 虽然这些系统 ( 现在称为手持式 PC2000) 在消费领域没有成功, 但在工业领域找到了市场 它凭借相对低的费用, 大屏幕和长时间电池能力满足了这个机会市场

4 2001 年晚些时候,Pocket PC 更新为 Pocket PC 2002 这次发布使用了 Windows CE3.0 的最终发布版本, 并做了一些用户接口方面的改进 同时也增加了 Pocket PC Phone 版本, 在 Pocket PC 设备中集成了蜂窝电话支持功能 这些设备具有了 Pocket PC 的功能, 也具有蜂窝电话的联通功能, 形成了新一代的几乎可以始终连接的移动软件 微软的另一组人发布了 Smart Display( 译者注 : 一种具有触摸屏的无线监视器, 可以通过 b 无线网络连接到个人计算机, 并使用 Windows XP Professional 操作系统的 Remote Desktop ( 远程桌面 ) 来访问主机 ) 它使用 Windows CE.NET 4.1 系统, 具有平板式设备形式, 有无线网络访问能力, 有一个底座可以连接到 PC 上 当使用底座的时候, 它可以做第 2 个显示器 当不用底座的时候, 它可作为 PC 的移动显示器 2003 年春季,Pocket PC 团队发布了升级版的 Pocket PC, 称为 Pocket PC 2003 系统在用户接口方面没有很多变化, 但由于是基于 Windows CE.NET 4.2, 所以在稳定性和性能方面都有了巨大改进 Pocket PC 2003 还集成了蓝牙支持功能,OEM 厂商可以选择是否包含该功能 微软还和 OEM 厂商合作生产基于 Windows CE 的蜂窝电话 这些电话中的少部分被称为 Smartphone( 智能电话 ), 在 2002 年末发布了, 最初是基于 Windows CE 年升级到了 Windows CE4.2, 并增加了一系列特征, 包括.NET runtime 功能 新设备一直不断在发布, 例如 Media to Go 设备, 就是使用硬盘来存储的移动视频播放器 Windows CE 操作系统的强大功能, 使应用程序凭借运行在这些设备上的简单操作系统超越了系统能力 操作系统 虽然面向消费者的产品可以不断产生新闻热点, 但最重要的开发工作仍然在操作系统自身 Windows CE 从 1.0 之日就开始不断演化, 当它还是一个简单的管理器操作系统时就被寄予厚望 从 Windows CE 2.0 开始一直持续到今日, 微软不断发布 Windows CE 的嵌入式版本, 使开发者可以用在他们自定义的硬件上 虽然像 Pocket PC 等消费平台占据了宣传的主体, 但对基本操作系统的改进是使诸如 Pocket PC 和 Smartphone 之类的设备能够运做的基础 在 Fall Comdex 1997 大会上,Windows CE 2.0 随着手持式 PC 2.0 一起发布了 Windows CE 2.0 增加了网络支持, 包括 Windows 标准网络功能, 支持 NDIS miniport 驱动模式, 以及通用 NE2000 网络卡驱动支持 虽然增加的 COM 被限制在进程内服务, 但可以用来支持脚本编写 引入了新的显示驱动模式, 可以支持像素深度, 而不再是 Windows CE 1.0 中原始的每像素 2 位了 Windows CE 2.0 是 Windows CE 操作系统中第一个与诸如 H/PC 等产品分离, 独立发布的版本 开发者可以购买 Windows CE 嵌入式工具包 (ETK), 它可以让开发者为特殊的硬件平台定制 Windows CE 然而, 用过 ETK 后, 开发者会发现, 这个产品的功能还没有达到它所宣称的目标 随着掌上电脑 (Palm-size PC) 在 1998 年初发布后,Windows CE 又在不断改进 虽然 Windows CE 2.01 没有按 ETK 形式发布, 但它在减少操作系统和应用程序大小方面做的努力还是值得称道的 在 Windows CE 2.01 中,C 运行时库从每个 EXE 和

5 DLL 都要绑定的静态链接库中去掉了, 放到了操作系统里 这极大的减小了操作系统和应用程序的大小 1998 年 8 月, 微软发布了 H/PC, 配套的发布了操作系统的新版本 版 Windows CE 2.11 是从未正式发布的 Windows CE 2.1 的服务升级包 这一年年末,Windows CE 2.11 作为 Windows CE 平台的 2.11 版本, 发布给了嵌入式开发者社区 该版本支持改进的对象存储, 允许要存储的文件大于 4M 还增加了对控制台程序的支持, 同时增加了 MS-DOS 风格的命令行解释器 CMD.exe 的 Windows CE 支持 Windows CE2.11 还增加了 Fast IR, 用于支持 IrDA 的 4M 红外线标准, 同时增加了一些特殊功能来支持 IP 多点传送 最初的安全概念被引入 : 设备可以检查和拒绝装载没有被认证的模块 Windows CE 2.12 也是作为 2.1- 白桦 (Windows CE 2.1 的代号 ) 的服务包发布的 这次发布中最大的亮点是一个增强的平台 Builder 工具集, 它具有一个图形化的前端界面 用一个新的通知接口调整了系统操作, 新的接口将不同的通知功能进行了组合 通知的用户接口暴露在平台 Builder 中, 允许嵌入式应用开发者定制通知对话框 微软基于 PC 的 Internet 浏览器 IE 4.0 也被引入到 Windows CE 中, 称为 Genie- 通用 IE 控件 这个 HTML 浏览器控件完善了简单小巧的 Pocket Internet 浏览器 微软消息队列 (MMQ) 也被加了进去 Windows CE 2.11 中的安全功能 运行 / 不运行 (go/no go) 也增加了 运行, 但不信任 (go,but don't trust) 的选项 这样, 不被信任的模块可以运行, 但不能调用关键功能集, 也不能修改注册表的某些部分 期待已久的 Windows CE 3.0 终于在 2000 年中发布了 这次发布是跟随同年 4 月发布的 Pocket PC 的, 它使用了 Windows CE 3.0 略早一些的内部版本 Windows CE 3.0 最大的亮点在它的内核, 内核为更好的支持实时功能而做了优化 增强后的内核, 支持 256 个线程优先级 ( 之前的版本是 8 个 ), 可调整线程周期, 可嵌套的中断服务程序, 并减少了内核等待时间 Windows CE 3.0 改进的地方不仅仅在内核上 一个新的 COM 组件被加入进来, 用来完善 2.0 就有的进程内 COM 功能 新的组件支持完整的进程外 COM 和 DCOM 功能 对象存储区域也做了改进, 可以支持 256M RAM 了 对象存储区域里的文件大小限制也提高到了 32M/ 文件 Platform Builder 3.0 的附加的软件包加入了更多的功能, 增加了 media player 控件, 提高了多媒体支持 用 PPTP,ICS 和远程桌面显示功能改进了网络支持 还正式引入了 DirectX API Windows CE 接下来的一个版本, 改变的不仅仅是新特性, 产品的名字也改了 2001 年初,Windows CE.NET 4.0 发布了 这个版本里, 改变了虚拟内存的管理方式, 将每个应用程序的虚拟内存空间扩大了 1 倍 Windows CE.NET 4.0 还增加了新的驱动装载模式, 服务 (Services) 支持, 新的基于文件的注册选项, 蓝牙功能, 以及 1394 支持 具有讽刺意味的是,Windows CE.NET 4.0 虽然叫.NET, 但却不支持.NET 精简框架 2001 年末,Windows CE 4.1 跟随 Windows CE 4.0 之后发布了, 增加了 IP v6 支持,Winsock2 支持, 一组支持 applets 的新功能, 以及一个叫 Power Manager 的例子 Windows CE 4.1 支持.NET 精简框架.NET 运行时库作为一个快速修复包 (QFE), 在操作系统发布后提供的

6 2003 第 2 季度,Windows CE.NET 4.2 发布了 这次升级, 提供了很棒的 OEM 厂商期待的新特性 - 在嵌入式系统上支持 Pocket PC 应用程序 Pocket PC 特有的 API, 比如菜单条 软输入法以及其它解释器特性, 被移植到基本操作系统里了 为支持名字空间扩展, 浏览器 Shell 被重写 通过在某些 CPU 上直接支持硬件分页表功能, 内核性能得到了改进 因为 Windows CE 不断在发展, 下个版本的 Windows CE 正在开发中, 一旦有新版本发布的信息, 我将更新到我的网站 为什么你应该读这本书 微软 Windows CE 程序设计 一书, 是为任何想给 Windows CE 或.NET 精简框架编写应用程序的人写的 嵌入式系统程序员为特定的应用使用 Windows CE,Windows 程序员对写或者移植一个已有的 Windows 程序很感兴趣, 甚至可管理代码的开发者都可以用本书里的信息来使他们的工作更容易 嵌入式系统上的程序员, 他们或许没有 Windows 程序员熟悉 Win32 API, 他们可以读本书第 1 部分的内容来熟悉 Windows 编程 虽然这一部分不如 Windows 程序设计 (Charles Petzold 著 ) 这类书能提供全面的指南, 但它的确提供了一些基本信息, 使读者可以读懂后面的内容 它也为嵌入式系统程序员开发复杂但很有用的 Windows CE 程序提供了帮助 有经验的 Windows 程序员可以通过本书学习 Windows CE 和 Windows XP 中 Win32 API 的差异, 两者之间的差异是很显著的 Windows CE 的小巧意味着 Win32 模式里的很多 API 不能被支持 Win32 API 的某些部分根本不被支持 另一方面, 因为 Windows CE 的特殊性,Windows CE 在许多领域扩展了 Win32 API, 本书将讲述这些领域 本书对使用.NET CF 的开发者也很有用 当前的 CF 在功能上有些缺陷 : 需要用可管理的应用程序来调用操作系统来执行某个任务 本书对从操作系统可以获得什么做了很好的指导 书中有一章节会讨论在基于 Windows CE 的设备中开发可管理代码所涉及的特性 本书通过例子来进行教学 我专门为本书写了许多 Windows CE 示例程序 例子的原代码列在了书中 源代码及最终编译后的程序可以在附书光盘里找到, 这些适合许多 Windows CE 支持的处理器 书中的示例都是直接用 API 写的, 即所谓的 Petzold 编程方式 由于本书的目标是教你如何为 Windows CE 编写程序, 所以示例都避免使用诸如 MFC 等类库, 应为这会使为 Windows CE 写应用程序所涉及的特性产生混乱 一些人可能会认为 Windows CE 中有 MFC, 了解 Windows CE API 的必要性就不那么大了 我并不这么认为, Windows CE API 的知识可以使你更有效的使用 MFC 我认为真正了解操作系统能够有效的简化应用程序的调试 第 3 版新内容第 3 版本做了比较大的修订, 增加了很多重要的内容, 包括 Smartphone 蓝牙等多

7 个新主题 本书更新了 Windows CE.NET 4.2 的新特性 增加了新的章节, 覆盖 Smartphone 和.NET CF 许多章节做了明显扩充, 覆盖了 OBEX 蓝牙和服务等主题 另有一些章节做了重新整理以更好的描述主题 为 Smartphone 以及 Pocket PC Phone 的通信特性增加了一章内容, 涉及如何为 Smartphone 2003 设备写应用程序 还讲述了在 Smartphone 和 Pocket PC Phone 上, 如何通过 SMS 系统, 使用联接管理器 发送和接收消息功能来写应用程序 新增了一章关于.NET CF 内容的, 涉及如何写 Windows CE 上可管理的应用程序 在此之后, 集中在.NET CF 的特殊类 Windows Form 的应用程序上 本章涉及的一个重要部分是, 当可管理类库不能提供应用所需的功能时, 如何在可管理的代码中调用不可管理或者本地代码 设备之间通信这一章节涉及蓝牙和 OBEX 蓝牙是一个无线通信标准, 但坦白地说, 在许多文章中并没有很好的解释说明 这一章介绍了蓝牙技术并提供了一个简单易懂的使用示例 本章还包括 OBEX 内容,OBEX 是蓝牙和红外线数字联盟使用的对象交换标准 本章另外一个例子演示了如何用 OBEX 通过蓝牙或者红外线数据方式去传送文件到其他设备 Pocket PC 这一章增加了 Pocket PC 2003 设备的新特性 本书第 2 版 Pocket PC 一章中的菜单条例子已经移到了通用控件这一章, 这表明出在最新的 Windows CE 版本中,Pocket PC API 将一些功能移到操作系统中 驱动程序和服务一章也做了更新, 涉及 Windows CE 服务 Windows CE 服务在 Windows CE.NET 4.0 中引入 Windows CE 服务程序为编写后台运行程序提供了方法, 避免为服务使用单独的进程所带来的开销 操作系统还提供超级服务来监控 IP 端口, 并在客户端连接该端口的时候通知服务 本章提供了一个简单的 Windows CE 服务例子, 演示了如何写服务程序和使用超级服务的特性 对本书第 1 版的读者来说, 本书包含了第 2 版的所有新特性 更新内容涉及 Pocket PC 和 Windows CE 设备驱动程序, 以及第 1 版发布后, 实现的新的内容管理和线程特性.NET 精简框架 一个开发者没有听说过微软的.NET 计划, 那他一定是在荒岛上 该计划包括一个运行时环境, 把代码从硬件上隔离开, 同时提供一个类型安全的运行时环境以增加安全性 为嵌入式和电池供电的设备编写了更小一些的运行库.NET 精简框架的最初版本运行在有 Windows CE 的 Pocket PC 和基于 Windows CE.NET 4.1 及以后的嵌入式系统上 嵌入式设备的特殊要求使得在它上面只用可管理的代码写应用程序成为一项挑战 嵌入式应用和一些移动应用要求应用程序和设备紧密的集成在一起 因为运行时库的特性之一就是将应用和硬件隔离, 所以一个嵌入式可管理的应用程序有时需要打破运行时库的限制, 直接访问某些操作系统的功能

8 正如前面所提到的, 在精简框架这一章节里, 花费了大量时间来讨论如何使可管理的应用程序访问操作系统 讨论涉及到一些技术, 比如通过跨越可管理 / 本地代码边界来聚集参数等, 当然, 在精简构架里完成这个任务比在桌面应用中更困难 关于 MFC 对于问是否该用 MFC 开发 Windows CE 下应用程序的人, 过去, 我通常的回答是 : 不要用 老版的 windows CE 系统加上比较慢的 CPU, 运行复杂 全功能的 MFC 应用会带来很大的压力 但现在, 我不再这么绝对了 新版的 Windows CE 平台足够快, 可以用合理的性能运行基于 MFC 的应用 MFC 运行时库包含在这些设备的 ROM 中, 所以应用程序仅仅是代码, 而不再是代码加 MFC 运行时库 但正像速度和运行库都已经加到平台里去一样,MFC 正逐渐没落 微软不再推荐 MFC 应用开发, 取而代之的是.NET 开发 所以你应该用 MFC 开发吗? 我的回答是不要再用 MFC 开发新项目 对于旧项目, 仍然有机会用 MFC, 但仅仅只是因为这些项目没有移植到其他开发平台上 Windows CE 开发工具本书假设读者了解 C 和熟悉微软 Windows, 在 XP 下用微软嵌入式 Visual C++ 开发过本地程序 为了编译书中的例子程序, 需要微软嵌入式 Visual C++ 4.0, 这可以在附书光盘中找到 需要相关的适合 Windows CE 设备的 SDK, 用于你的目标设备 每个例子已经有一个预先定义好的工程设置, 但你也可以选择从头创建一个工程 对大多数例子来说, 简单创建一个普通 WCE 应用程序工程就可以了 对于那些要求访问 Pocket PC 上特殊功能的例子, 即使整个工程设置不是特别为 Pocket PC 应用定义的, 也可以用特殊的代码链接这些功能 对那些想为 Pocket PC 2000 和 2002 写应用程序的开发者来说, 需要使用嵌入式 Visual C 不幸的是, 附书光盘没有足够的空间同时放 evc3 和 evc4, 但你可以从微软网站下载 evc3 还需要用于这些老版本 Pocket PC 系统的 SDK 一些例子, 例如蓝牙 OBEX 和服务等例子, 使用了老系统里没有的例子 用 Visual Studio.NET 2003 可以开发.NET 精简框架应用程序 因为太大和非免费, 所以没有在光盘里提供 当然, 这个工具是非常高效的开发工具 那些对开发可管理代码感兴趣的人来说, 开发效率提高减轻了升级花费所带来的痛苦 在精简框架这一章, 你需要 Visual Studio.NET 2003 来编译里面的例子 该工具为所有的 Pocket PC 设备以及基于 Windows CE 4.1 以上的嵌入式版本提供了必要的运行时库 目标系统你并不需要 Windows CE 目标设备来体验书中提供的例子 各种 SDK 平台都带有 Windows CE 模拟器, 让你可以在 Windows XP 对 Windows CE 程序下执行基本测试 在你手边没有实际的设备的时候, 可以很方便地使用模拟器 模拟器执行 PC 模拟器中的 Windows CE 版本, 而 PC 模拟器会在 PC 上执行一个实际的 Windows CE 操作系统

9 在决定使用哪种 Windows CE 硬件来测试的时候, 你应该考虑很多因素 首先, 如果应用程序式一个商业产品, 你至少应该为每种目标 CPU 购买一个系统 你需要在所有目标 CPU 上进行测试, 因为虽然源代码可能相同, 但执行结果可能不同, 并且每种目标 CPU 分配的内存大小也不同 CD 里的内容附书光盘包含了书中所有例子的源代码 我提供了 MS evc 的工程文件, 你可以打开这些预配置的文件 所有的例子都是为 Windows CE 4.2 Pocket PC 2003 和 Smartphone 2003 设计的 除了例子, 光盘中还包含免费的 evc 这和你从微软站点下载或者通过光盘购买的版本一样, 可以把这些工作看作是赠品 还包括了 Pocket PC 2003 的平台 SDK 光盘还包括一个 StartCD 程序, 提供图形化界面, 让你可以访问 CD 里的内容 如果你开了 Windows 自动运行功能, 当你把光盘插到光驱中, 这个程序就会自动运行 如果不能自动运行, 进入 CD 根目录, 运行 StartCD.exe 即可 Readme.txt 文件为 CD 中的内容提供了更多的信息, 介绍了包含的工具和 SDK 的系统要求, 以及对包含产品的支持信息 下面是为了安装和运行 MS evc 所需要的系统要求 注意 evc 是运行在 Windows 2000, Windows XP, 或者 Windows Server 2003 上的 * 带 Pentium 处理器的 PC: 推荐 Pentium 150 MHz 或者更高 *Microsoft Windows XP, Windows 2000 Service Pack 2 (or later) or Windows Server 2003 *32 MB 内存, 推荐 48MB * 硬盘空间 : 最小安装 360MB, 完全安装 720MB * 带光驱 *VGA 或更高分辨率的显示器, 推荐 S VGA * 微软鼠标或兼容鼠标设备 其它资源虽然我试图将本书做成 一站式 的 Windows CE 编程书籍, 但没有一本书可以覆盖各个方面的 通常, 要了解更多 Windows 编程知识, 我推荐经典书籍 --Charles Petzold 写的 Windows 编程 ( 微软出版社,1998) 一书 这是迄今为止最好的 Windows 编程书籍 Charles 提供了例子, 演示如何解决困难而又常见的 Windows 问题 要更多的了解 Win32 核心 API, 我推荐 Jeff Richter 的 Windows 核心编程 (Programming Applications for Microsoft Windows (Microsoft Press, 1999)) Jeff 揭示了进程 线程和内存管理方面的很多细节技术 要了解更多的 MFC 编程知识, 没有比 Jeff Prosise 的 MFC 程序设计 ( Programming Windows with MFC (Microsoft Press, 1999). ) 更好的书籍了 这本书是 MFC 版的 Petzold 编程书籍, 可以说是 MFC 程序员必读 要更多的了解.NET 编程, 我推荐 Charles Petzold 的 C# Windows 程序设计 (Programming Windows with C# (Microsoft Press, 2002)) Charles 将他令

10 人惊叹的技巧应用到了.NET 框架的 Windows Form 中 这是赶上.NET 客户端编程发展速度的一本非常的好书 WinCE 程序设计 (3rd 版 )-- 第一章 Hello Windows CE- 概述 概述 从经典的 The C Programming Language 一书开始, 传统上编程方面的书都是从 "Hello,world" 程序开始的 这是一个合理恰当的开始 每个程序都有一个基本底层结构, 分析它可以揭示所有运行在这个操作系统上的应用程序都具有的基础, 避一些设计复杂的任务将结构搞的难以理解 在本书 "Hello,world" 一章里, 包含了关于设置和使用编程环境的细节 用于开发微软 Windows CE 应用程序的环境与开发标准微软 Windows 应用程序的环境有些不同, 因为 Windows CE 程序是在运行 XP 的 PC 机器上编写, 却主要在独立的基于 Windows CE 的目标机器上进行调试的 经验丰富的 Windows 程序员可能会跳过这一章进入有更多内容的主题, 但我建议你至少浏览一下本章, 了解标准 Windows 编程和 Windows CE 编程之间的区别 两个开发过程中许多细微而又重要的不同之处和 Windows CE 应用程序的基本构架包含在第一章里 1.1 Windows CE 有什么不同之处 Windows CE 有什么不同之处 Windows CE 有许多特性使得它不同于其它 Windows 平台 首先, 运行 Windows CE 的系统, 大多数可能不使用 Intel x86 兼容微处理器 实际上, Windows CE 运行在 4 种不同的 CPU 系列里 :SHx, MIPS, ARM, 和 x86 幸运的是, 开发环境几乎将各种不同 CPU 的所有差异与程序员隔离开了 Windows CE 程序事先不能确定屏幕或键盘 Pocket PC 设备有一个 240*320 的纵向屏幕, 而其它系统具有传统的 480*240,640*240,640*480 像素分辨率的横向屏幕 一些嵌入式设备则根本没有显示器 一些目标设备可能不支持彩色, 并且大部分 Windows CE 设备用触摸屏替代了鼠标 一些在触摸屏设备上, 轻触屏幕, 表示鼠标左键点击, 没有明显的方法代表鼠标右键 为了能处理右键, Windows 约定, 当轻触屏幕的时候, 按下 Alt 键, 由 Windows CE 程序把这个组合序列解释为鼠标右键点击 Windows CE 设备具有更少的资源运行 Windows CE 系统的目标设备上, 各种资源变化极大 当写一个标准 Windows 程序的时候, 程序员可以对目标设备做许多假定, 并且设备几乎都是 IBM 兼容机 目标设备通常有硬盘用于存储, 同时虚拟内存系统用硬盘作为交换设备来模拟一个几乎没有数量限制的虚拟内存 程序员知道用户有键盘 双键鼠标以及可以当前支持 256 色 至少有 800*600 分辨率的显示器

11 Windows CE 程序所运行的设备几乎都没有硬盘作为大容量存储 没有硬盘不仅仅意味着没有地方存储大量文件, 也意味着不能交换数据到磁盘上来创建虚拟内存 所以 Windows CE 程序几乎总是在少量内存环境里运行的 因为资源缺乏, 内存分配经常失败 当空闲内存达到一个严重低的级别,Windows CE 可能会自动终止一个程序 RAM 的限制对 Windows CE 程序有很大的影响, 并且是将现有的 Windows 应用程序移植到 Windows CE 过程涉及的主要挑战之一 Unicode 在写 Windows CE 程序时, 程序员可以使用的一个特性是 Unicode. Unicode 是一个字符编码标准, 使用 16 位表示一个字符, 相对的,ASCII 标准是用单个 8 位编码一个字符 Unicode 允许相当简单将程序移植到不同的国际市场, 因为世界上所有已知的字符都可以用 65,536 个 Unicode 值里的一个来表示 处理 Unicode 相对容易, 只要避免假设字符串是用 ASCII 代表和字符是按单个字节存储的 使用 Unicode 的一个结果是每个字符占 2 个字节而不是一个, 字符串长了一倍 程序员必须小心计算缓冲区和字符串的长度 你不能再假设 260 字节可以存储 259 个字符和一个 0 结尾符 作为标准 char 数据类型的替代品, 你应该使用 TCHAR 数据类型 TCHAR 在 MS Windows 95 和 98 中定义为 char 型, 在 Windows 2000,XP,Windows CE 中, 使用 Unicode 功能的程序里,TCHAR 定义为 unsigned short 类型 这些类型定义, 允许在基于 ASCII 和 Unicode 的操作系统上源代码级的兼容 新控件 Windows CE 上有许多为特殊环境设计的新控件 包括命令条 菜单条控件, 提供类似菜单和工具条的功能, 在具有更小屏幕的 Windows CE 设备上, 这些为了节省空间都合并一行里 其它控件也为 Windows CE 做了改进 Windows CE 里的编辑控件 (edit control) 可以设置为自动将单词首字母大写, 这对在无键盘的 PDA 上进行设计是很重要的 对于 Windows 桌面版本里的控件, Windows CE 则提供了大部分 例如, 日期和时间调整控件 日历控件使日历和管理器应用程序更加适合诸如 H/PC 和 Pocket PC 等手持设备 其它

12 Windows 标准控件做了功能裁减, 这反应了 Windows CE 特殊的硬件系统配 置所具有的紧凑简洁特性 组件化 Windows CE 编程中另一个需要注意的方面是 Windows CE 可以被微软或 OEM 厂商分解和重新配置, 以更好地适应目标市场或设备 Windows 程序员通常只是检查 Windows 版本, 看是否是 Windows 95/98,Me 系列或者 2000,XP 系列 通过获得版本, 程序员可以判断哪些 API 函数可以使用 然而,Windows CE 可以按无数种方式配置 迄今为止,Windows CE 最流行的配置是 Pocket PC 微软定义了具体 Windows CE 组件集合, 这些都体现在所有称为 Pocket PC 的设备上 然而, 一些用 Windows CE 生产的 OEM 产品 --PDA 设备, 并不叫 Pocket PC 这些设备同 Pocket PC 设备在 API 上略微不同 如果你没有意识到这一点, 你很容易写一个程序能运行在一个平台, 却不能运行在另一个平台 在嵌入式平台上, OEM 厂商决定包括什么组件, 并可以为它特定的平台创建一个 SDK 开发包 如果 OEM 厂商对第三方开发感兴趣, 它会为它的设备提供一个可定制的 SDK 包 新的平台不断出现, 它们有许多共同的地方, 也有许多不同之处 程序员需要了解目标平台, 在尝试用一个可能不被设备支持的功能集时, 需要让程序检查在特殊平台上什么函数可用 Win32 子集最后, 因为 Windows CE 比 XP 小很多, 它不能像它大块头的兄弟 XP 那样支持所有的函数调用 当你面对一个不支持打印功能的操作系统, 比如原始模式下的 Windows CE 时, 不要调用任何打印函数,Windows CE 还去除了一些 XP 中支持的冗余功能 虽然 Windows CE 可能不支持你喜欢的功能, 但其它不同的函数集可能会工作的很好 有时 Windows CE 编程似乎主要是用 Windows CE 中稀少的 API 来找出实现一个特性的方式, 虽然成千上万的函数很少被调用 1.2 依然是 Windows 编程

13 依然是 Windows 编程虽然 Windows CE 和 Windows 的其它版本之间确实存在差异, 但不应该夸大这种差异 编写 Windows CE 应用程序依然是编写 Windows 应用程序 有同样的消息循环, 同样的窗口, 大部分情况下, 具有同样的资源和控件 差异并不会掩盖相同的地方 匈牙利命名方式是重要的相同点之一 匈牙利命名方法自从 Charles Petzold 写 Windows 程序设计 一书开始, 大部分 Windows 程序都采用了匈牙利命名方法, 这是一种传统和良好的命名方法 这种编程风格是 Charles Simonyi 多年前在微软发明的, 它给程序里每个变量用 1 到 2 个字母的前缀来表示变量的类型 例如, 命名为 Name 的字符串数组应该命名为 szname, 前缀 sz 表示变量类型是以 0 做终止符的字符串 匈牙利命名法的价值在于极大的提高了源程序的可读性 其它的程序员, 或者你看一段代码, 不应该重复的看变量声明来判定变量的类型 表 1-1 列出了变量典型的匈牙利前缀 表 1-1 变量的匈牙利前缀 变量类型 Integer Word (16-bit) Double word (32-bit unsigned) Long (32-bit signed) Char String Pointer Long pointer Handle Window handle Struct size 匈牙利前缀 i or n w or s Dw L C Sz P lp h hwnd cb 你可以看到 Windows 早期的一些痕迹 lp 或者长指针, 在 Intel 16 位编程模 式下, 指针分位短指针 (16 位偏移 ) 和长指针 ( 附加偏移段 ) 其它前缀由类

14 型的缩写构成 例如, 刷子的句柄通常是 hbr 前缀可以是组合的, 就像 lpsz, 指出一个以 0 结尾的长指针 Windows API 中大部分结构是采用匈牙利表示法来给它们的域命名的 本书通篇使用这种命名法 我鼓励你在你的程序里用这种命名方法 1.3 第一个 Windows CE 程序 第一个 Windows CE 程序说了这么多, 就让我们一起看一下你的第一个 Windows CE 程序吧 列表 1-1 显示了 Hello1-- 为 Windows CE 写的一个简单的 Hello World 应用程序 Listing 1-1: Hello1, 一个简单的 Windows 应用程序 Hello1.cpp ================================================= ===================== Hello1 - A simple application for Windows CE Written for the book Programming Windows CE Copyright (C) 2003 Douglas Boling ================================================= ===================== #include "windows.h" Program entry point int WINAPI WinMain (HINSTANCE hinstance, HINSTANCE hprevinstance, LPWSTR lpcmdline, int ncmdshow) { printf ("Hello World\n"); return 0;

15 如您所见, 除了程序入口点外, 代码看上去十分类似经典的 Kernighan 和 Ritchie 版程序 在注释之后, 有一行代码 #include "windows.h" 这个文件包含了一组文件, 它们中定义了 Windows API 及其用到的结构和常量 程序的入口点是本程序和标准 C 程序之间最大的差别 作为 C 标准入口 int main (char **argv, int argc) 的替代品,Windows CE 通过标准 Windows 入口点 [ 注 1] int WINAPI WinMain (HINSTANCE hinstance, HINSTANCE hprevinstance, LPWSTR lpcmdline, int ncmdshow); 构建程序环境 Windows CE 在一些方面不同于桌面版的 Windows 第 1 个参数,hInstance 为其它应用程序指明具程序实例, 也为需要验证这个 EXE 的 Windows API 函数提供了程序实例 参数 hprevinstance 是从旧的 Win16 API(Windows 3.1 及更早的系统 ) 遗留下来的 包括 Windows CE 在内的所有 Win32 操作系统中,hPrevInstance 始终是 0, 可以忽略掉 参数 lpcmdline 指向一个 Unicode 字符串, 包含了命令行文本 从微软 Windows CE 浏览器启动的应用程序没有命令行参数, 但在某些情况下, 例如当系统自动启动一个程序时, 系统包含一个命令行参数来说明程序为什么被启动 参数 lpcmdline 是 Windows CE 与 XP 出现差异的情况之一, 在 Windows CE 里, 命令行字符串是 Unicode 字符串, 在其它版本的 Windows 里, 命令行字符串总是 ASCII 的 最后一个参数,nCmdShow, 指明了程序主窗口的初始状态 由父进程, 通常是浏览器传递这个参数到程序里 它对应用程序如何配置主窗口给出了说明 该参数可能会规定窗口最初显示成图标 (SW_SHOWMINIMIZE), 或者显示最大化 (SW_SHOWMAXIMIZED) 来覆盖整个桌面, 或者显示为普通 (SW_RESTORE) 大小来表明窗口按标准可变大小方式显示在屏幕上 其它值

16 规定窗口初始状态对用户不可见, 或者规定窗口可见但不能成为活动窗口 在 Windows CE 里, 这个参数的值被限制成 3 个状态 : 普通 (SW_SHOW) 隐藏 (SW_HIDE) 和非激活显示 (SW_SHOWNOACTIVATE) 除非应用程序需要强制它的窗口预先确定状态, 在程序主窗口被创建后, 这个值是不加修改, 只是简单的传递给 ShowWindow 函数的 下一行是这个应用程序唯一的功能行 : printf ("Hello World\n"); Windows CE 支持大部分标准 C 库, 包括 printf,getchar 等等 这一行有趣的地方在于它不像 Windows CE 其它任何地方, 这个串不是 Unicode 而是 ANSI 下面是对这个现象的合理解释 : 对于用 ANSI 标准编译的 C 标准库,printf 和诸如 strcpy 等其它字符串库函数用的是 ANSI 字符串 当然,Windows CE 支持这些标准函数的 Unicode 版, 例如 wprintf, getwchar, 和 wcscpy 最后, 用 return 0; 结束程序 其它进程可以用 Win32 API 函数 GetExitCodeProcess 获取返回值 构建第一个应用程序要在你的系统上从头创建 Hello1, 可以启动 MS evc++, 在 [File] 菜单上选择 [ 新建 ] 创建一个新工程 当看到新工程的对话框, 可以明显的看到 WinCE 编程与标准 Win32 编程的变化 你有机会选择在图 1-1 中所显示的各种平台 对于非 MFC 或 ATL 工程, 首选是 WCE Pocket PC 应用 ( 用于 Pocket PC) 和 WCE 应用 ( 用于其它 Windows CE 系统 ) 您还可以选择适当的目标 CPU 例如, 选择 Win32(WCE MIPI) 来为使用 MIPS CPU 的 Windows CE 平台编译程序 无论是何种目标设备, 都要确保选择 WCE 模拟器 这样你就可以在用 XP 下的模拟器中运行例子程序了 图 1-1 平台列表使 evc++ 能够面向不同的 Windows CE 平台 接下来,eVC++ 会询问您是否想创建一个空的工程 一个简单程序或者一个 Hello World 应用 对本书里所有的例子, 都选择空工程 这样做是为了避免代码向导向例子添加任何额外的代码 在 [File] 菜单选择 [New],Hello1.cpp 创建新文件

17 当为 Hello 1 创建或从 CD 复制了合适的源文件, 选择 Win32(WCE x86em) Debug 作为目标平台, 之后 build 这个程序 这一步会编译源代码, 如果没有编译错误的话, 系统自动启动模拟器, 并把 EXE 程序放到模拟器文件系统里, 接下来你可以启动 Hello1 如果你在 Windows 98 或 Me 系统下, 模拟器系统能够会显示一个错误信息, 因为模拟器只能在 Win2000 或 XP 下运行 如果你有 Windows CE 系统, 比如 Pocket PC(PPC), 把 PPC 连接到 PC 上, 方法和同步 PC 的内容到 PPC 一样 打开微软 ActiveSync, 建立 PPC 和 PC 的链接 为了 Windows CE 设备能够运行, 虽然 ActiveSync 链接并不是必须的, 但我发现让它运行可以为开发环境和 Windows CE 系统之间建立一个更稳定的链接 一但 PC 和 Windows CE 设备之间的链接成功和运行, 切换回 evc++, 选择合适的目标设备 ( 如适合 ipaq Pocket PC 的 Win32 [WCE ARM] Debug) 进行编译和 rebuild 和为模拟器创建程序一样, 如果没有错误,eVC++ 自动下载编译程序到远程设备上 程序要么被放到对象存储的根目录上, 要么放在 \windows\start 菜单目中 运行该程序要在嵌入式 Winodows CE 设备 H/PC 上运行 Hello1, 单击手持式 PC 的 My Computer 图标, 找到根目录下的文件, 之后双击应用程序图标启动程序 要在 Pocket PC 上运行程序, 从设备的 Start 菜单选择程序就可以了 因为 evc++ 已经把程序下载到 \windows\start 菜单所在的目录了 这种方式下, 下载的应用程序自动显示在 Start 菜单里 有问题? 如果在 Pocket PC 上点击图标或开始菜单选择 Hello1 程序, 似乎没什么反应 在手持式 PC 上, 程序似乎只是刷新了一下屏幕 这是因为程序启动 写到控制台并结束了 除非你从一个已经创建的控制台启动程序, 否则 Windows CE 会在 Hello1 执行 printf 语句时, 创建一个控制台窗口, 并且在 Hello1 结束的时候自动关闭控制台 在 Pocket PC 上, 应用程序可以运行, 但 Pocket PC 并不为诸如 printf 之类的输出提供控制台显示的功能 通过把驱动程序 console.dll 放到 Pocket PC 的 Windows 目录里, 可以为 Pocket PC 增加控制台支持 驱动程序从驱动程序接口获取输入, 创建屏幕窗口, 打印输出字符串 控制台启动程序可以从手持式 PC 和嵌入式版本的 Windows CE 获得 注 1: 虽然从技术上可以改变入口点原型来匹配 C 的标准入口点, 但通常不值得这么麻烦的 1.4 Hello2

18 Hello2 既然已经有了基础, 那么是时候把 Hello1 升级一下, 至少应该让人可以看见它 因为很多 Windows CE 系统没有控制台驱动程序,Hello2 创建一个消息框而不是用 printf 来显示 Hello CE 文字 Hello2 的程序如下表 1-2 所示 : 列表 1-2: Hello2, 使用 MessageBox 函数的简单应用程序 Hello2.cpp ================================================= ===================== Hello2 - A simple application for Windows CE Written for the book Programming Windows CE Copyright (C) 2003 Douglas Boling ================================================= ===================== #include "windows.h" Program entry point int WINAPI WinMain (HINSTANCE hinstance, HINSTANCE hprevinstance, LPWSTR lpcmdline, int ncmdshow) { MessageBox (NULL, TEXT ("Hello World"), TEXT ("Hello2"), MB_OK); return 0; 编译并运行 Hello2, 可以看到如图 1-2 所示的小窗口 图 1-2( 略 ) 运行在 Windows CE 桌面的 Hello2 替代 printf 的 MessageBox 函数为 Hello2 提供了 2 个特性 第一个也是最明显的一个就是它 创建一个窗口, 并在上面显示 "Hello World" 文本 第二个特性是 MessageBox 函数直到用户 关闭消息窗口才会返回 这允许 Hello2 一直保持运行, 直到用户关闭窗口 MessageBox 函数原型如下 : int MessageBox (HWND hwnd, LPCTSTR lptext, LPCTSTR lpcaption, UINT utype); 第 1 个参数是顶层窗口的句柄, 它是消息窗口的父窗口 目前我们把这个参数置为 NULL, 因为 Hello2 还没有任何其它窗口 第 2 个参数是准备显示在窗口里的文字 注意传入的字符串是用 TEXT 宏包裹的, 确保它能够编译成 Unicode 版本 第 3 个参数 lpcaption 是显示在窗口标题栏的文字 最后一个参数 utype 是一系列标志位, 规定消息框如何显示在屏幕上 标志位规定了消息框中按扭的数量和类型, 规定了图标的类型以及消息框窗口的风格设置

19 表 1-2 列出了 Windows CE 下有效的标志位 表 1-2: 默认标志位 标志位 按钮或者图标 用于按钮 MB_OK OK MB_OKCANCEL OK and Cancel MB_RETRYCANCEL Retry and Cancel MB_YESNO Yes and No MB_YESNOCANCEL Yes, No, and Cancel MB_ABORTRETRYIGNORE Abort, Retry, and Ignore 用于图标 MB_ICONEXCLAMATION, MB_ICONWARNING Exclamation point MB_ICONINFORMATION, MB_ICONASTERISK Lower case i within a circle MB_ICONQUESTION Question mark MB_YESNO Yes and No MB_ICONSTOP, MB_ICONERROR, MB_ICONHAND Stop sign MB_DEFBUTTON1 First button MB_DEFBUTTON2 Second button MB_DEFBUTTON3 Third button For Window Styles:

20 标志位 按钮或者图标 MB_SETFOREGROUND Bring the message box to the foreground. MB_TOPMOST Make the message box the topmost window. MessageBox 的返回值指出用户按了哪个按扭 返回值如下 : IDOK OK button pressed IDYES Yes button pressed IDNO No button pressed IDCANCEL Cancel button pressed or Esc key pressed IDABORT Abort button pressed IDRETRY Retry button pressed IDIGNORE Ignore button pressed 此时值得注意的是, 如果你调试和重新编译这个程序, 它不会被再次下载到目标设备上的, 因为程序早先的版本仍然正在目标系统上运行 换句话说, 当您在 evc++ 中启动一个新的 build 时, 您要确保 Hello2 没有运行在远程系统上, 否则编译过程里的自动下载过程就会失败 如果发生这种情况, 关闭应用程序, 选择 evc++ 里 [Update Remote File] 菜单命令去下载新的编译后的文件 Hello2 展示了一个简单的窗口, 但窗口只能按 MessageBox 函数允许的形式进行配置 如何显示一个完全由程序配置的窗口呢? 在我们这样做之前, 对 Windows 应用程序如何工作的做一个快速浏览是必要的 WinCE 程序设计 (3rd 版 )--1.5 Windows 应用程序剖析 Windows 应用程序剖析基于 Windows 的编程远不同于基于 MS-DOS 或 Unix 的编程 只要是程序需要, 任何时候基 于 MS-DOS 或 Unix 的程序都可以使用 getc- 或 putc 风格的函数从键盘读取字符并写到屏幕 上 这是 MS-DOS 或 Unix 程序所使用的典型的 "Pull"( 拉 ) 风格, 这种风格是面向过程的, 而一个 Windows 程序, 则使用 "Push"( 推 ) 模式 在这种模式下, 必须编写程序来响应来自 操作系统的通知, 比如一个键被压下去了或者收到一个重绘屏幕的命令

21 Windows 应用程序并不从操作系统请求输入, 而是由操作系统通知应用程序输入产生了 操作 系统通过发送消息 (messages) 给应用程序窗口来完成这些通知 所有窗口都是窗口类的具体 实例 在进一步深入之前, 让我们先确保理解这些术语 窗口类窗口是屏幕上的一个区域, 除了特殊情况, 基本上都是矩形 窗口有一些基本参数, 比如位置参 数 --x,y 和 z( 窗口在屏幕其它窗口之上或者之下 )-- 可视性以及层次关系 -- 窗口与系统桌面形 成父子窗口关系, 系统桌面也是一个窗口 每个被创建的窗口都是窗口类的一个具体实例 窗口类是一个模板, 为该类的所有窗口定义了许 多共同属性 换句话说, 属于同一个类的窗口有同样的属性 这些共享的属性中最重要的是窗口 过程 窗口过程窗口类里窗口过程中的代码定义了同一个类里所有窗口的行为 窗口过程处理发到窗口的所有通 知和请求 这些通知, 要么是操作系统发给窗口, 告诉窗口有事件发生, 窗口必须回应, 要么是 其他窗口发来的, 向该窗口查询信息 这些通知是以消息的形式发送的 消息实际就是对窗口过程的一次调用, 带有参数指出通知或者 查询的种类 当有事件发生, 例如窗口被移动 被改变大小或有键被按下去等, 就会发送消息 标识消息的值由 Windows 定义 应用程序使用预定义好的常量, 例如 WM_CREATE 和 WM_MOVE, 来表示消息 因为有很多消息可被发送, 所以当窗口类对某个消息没有特殊处理 的必要时,Windows 提供了一个默认处理函数来处理传递这些消息 消息生命周期 让我们回头一会, 看一下 Windows 是如何协调发到系统里各个窗口的各种消息的 Windows 监视系统的所有输入, 例如键盘 鼠标 触摸屏以及其它可以产生影响窗口的事件的硬件 当事 件发生后, 消息就被构成并定向给特定的窗口 Windows 没有直接调用窗口过程, 而是加了一 个中间步骤 消息被放到拥有该窗口的应用程序的消息队列里了 当应用程序准备接收消息的时 候, 它把消息从队列里取出来, 并告诉 Windows 发送该消息到应用程序适当的窗口上 你可能会认为这个过程中涉及许多中间步骤, 那么你是对的 就让我们分解一下这个过程吧 1 当事件发生,Windows 就构成一个消息并放到拥有目的窗口的应用程序的消息队列里 和 在 XP 里一样, 在 Windows CE 中, 每个应用程序有自己单独的消息队列 [1] ( 这与 Windows3.1 及更早的 Windows 版本不同, 那时只有唯一一个系统范围内的消息队列 ) 事 件发生及构成一个消息都要比应用程序处理它们的速度快 虽然程序最好能快速响应或者用户希 望看到应用程序快速响应, 但是队列允许应用程序按自己的速率处理消息 消息队列允许 Windows 在运做中设置一个通知并继续完成其它任务, 而不是仅仅限制在只响应收到消息的这 个应用程序 2 应用程序把消息从消息队列中移出来, 并回调 Windows 来分派消息 似乎很奇怪应用程序 从队列里获得消息却只是简单的回调 Windows 来处理这个消息, 对这种方式, 解释如下 : 应用 程序从队列里获取消息, 这使得应用程序在请求 Windows 把消息分派到相应窗口之前, 可以预 处理这些消息 许多情况下, 应用程序会调用 Windows 里不同的函数来处理具体的各种消息 3 Windows 分发消息, 更确切的说, 是 Windows 调用相应的窗口过程 没有让应用程序直 接调用窗口过程, 而是间接调用, 这允许 Windows 协调这个窗口过程的调用与系统里的其它事 件 虽然此刻消息并不在另外一个队列里, 但 Windows 在调用窗口过程之前, 可能需要做一些

22 预处理 但无论如何, 这种调度方式减少了应用程序的责任, 不用程序去决定适当的目的窗口, 而是由 Windows 负责了 4 窗口过程处理消息 所有的窗口过程都有相同的调用参数: 被调用的窗口实例的句柄 消息参数 两个普通参数, 包含与消息相关的数据 窗口过程用窗口句柄区分窗口的每个实例 消息参数, 指明窗口必须响应的事件 两个普通包含与消息相关的数据 例如,WM_MOVE 消息指出窗口将被移动, 其中一个普通参数指向一个包含窗口新坐标的结构 注 : 技术上,Windows CE 应用程序的每个线程都有一个消息队列 稍后我将在本书里讨论线程 WinCE 程序设计 (3rd 版 )--1.6 Hello3 Hello3 回顾的够多了, 是时候做一个完整的 Windows 应用程序 --Hello3 了 虽然 Hello3 的整个程 序文件以及书中全部例子都可以在附书光盘里找到, 但我还是建议, 对于初期的例子, 您应当避 免简单的从 CD 上装载工程文件, 而是应该手工输入整个例子 通过这种略微有些枯燥的工作, 你会体会到标准 Win32 程序与 Windows CE 程序之间在开发过程的不同以及在程序上的细微 差别 清单 1-3 给出了 Hello3 的全部源代码 清单 1-3: 程序 Hello3 Hello3.cpp ================================================= ===================== Hello3 - A simple application for Windows CE Written for the book Programming Windows CE Copyright (C) 2003 Douglas Boling ================================================= ===================== #include <windows.h> For all that Windows stuff LRESULT CALLBACK MainWndProc (HWND, UINT, WPARAM, LPARAM); ================================================= ===================== Program entry point int WINAPI WinMain (HINSTANCE hinstance, HINSTANCE hprevinstance, LPWSTR lpcmdline, int ncmdshow) { WNDCLASS wc; HWND hwnd; MSG msg; Register application main window class. wc.style = 0; Window style

23 wc.lpfnwndproc = MainWndProc; Callback function wc.cbclsextra = 0; Extra class data wc.cbwndextra = 0; Extra window data wc.hinstance = hinstance; Owner handle wc.hicon = NULL, Application icon wc.hcursor = LoadCursor (NULL, IDC_ARROW); Default cursor wc.hbrbackground = (HBRUSH) GetStockObject (WHITE_BRUSH); wc.lpszmenuname = NULL; Menu name wc.lpszclassname = TEXT("MyClass"); Window class name if (RegisterClass (&wc) == 0) return -1; Create main window. hwnd = CreateWindowEx(WS_EX_NODRAG, Ex style flags TEXT("MyClass"), Window class TEXT("Hello"), Window title Style flags WS_VISIBLE WS_CAPTION WS_SYSMENU, CW_USEDEFAULT, x position CW_USEDEFAULT, y position CW_USEDEFAULT, Initial width CW_USEDEFAULT, Initial height NULL, Parent NULL, Menu, must be null hinstance, Application instance NULL); Pointer to create parameters if (!IsWindow (hwnd)) return -2; Fail code if not created. Standard show and update calls ShowWindow (hwnd, ncmdshow); UpdateWindow (hwnd); Application message loop while (GetMessage (&msg, NULL, 0, 0)) { TranslateMessage (&msg); DispatchMessage (&msg); Instance cleanup return msg.wparam; ================================================= ===================== MainWndProc - Callback function for application window

24 LRESULT CALLBACK MainWndProc (HWND hwnd, UINT wmsg, WPARAM wparam, LPARAM lparam) { PAINTSTRUCT ps; RECT rect; HDC hdc; switch (wmsg) { case WM_PAINT: Get the size of the client rectangle GetClientRect (hwnd, &rect); hdc = BeginPaint (hwnd, &ps); DrawText (hdc, TEXT ("Hello Windows CE!"), -1, &rect, DT_CENTER DT_VCENTER DT_SINGLELINE); EndPaint (hwnd, &ps); return 0; case WM_DESTROY: PostQuitMessage (0); break; return DefWindowProc (hwnd, wmsg, wparam, lparam); Hello3 展示了 Windows 程序的各个方面, 从注册窗口类到创建窗口及窗口过程 和头两个例子一样,Hello3 有着相同的入口点 --WinMain 但是因为 Hello3 创建了自己的窗口, 所以它必须为主窗口注册一个窗口类, 创建窗口并且提供一个消息循环来为窗口处理消息 注册窗口类在 WinMain 中,Hello3 为主窗口注册了窗口类 注册一个窗口类只是简单的填充一个描述窗口类的有些大的结构并调用 RegisterClass 函数 RegisterClass 和 WNDCLASS 结构定义如下 : ATOM RegisterClass (const WNDCLASS *lpwndclass); typedef struct _WNDCLASS { UINT style; WNDPROC lpfnwndproc; int cbclsextra; int cbwndextra; HANDLE hinstance; HICON hicon; HCURSOR hcursor;

25 HBRUSH hbrbackground; LPCTSTR lpszmenuname; LPCTSTR lpszclassname; WNDCLASS; 给 WNDCLASS 结构各个域赋的值为 Hello3 主窗口的所有实例定义了行为表现 style 域为窗口设置了类的风格 在 Windows CE 中, 类风格被限制为 : CS_GLOBALCLASS 表示类是全局的 这个标志只是出于兼容性才提供的, 因为 Windows CE 中所有窗口类都是进程级全局类 CS_HREDRAW 告诉系统如果窗口改变了水平大小, 就强制重画窗口 CS_VREDRAW 告诉系统如果窗口改变了垂直大小, 就强制重画窗口 CS_NOCLOSE 如果 [ 关闭 ] 按钮出现在标题栏上, 则使其失效 CS_PARENTDC 让窗口使用父窗口的设备环境变量 CS_DBLCLKS 允许 [ 双击 ] 通知 (Windows CE 下敲击两次为双击 ) 传递给父窗口 lpfnwndproc 分配的是窗口的窗口过程的地址 因为该域定义为指向窗口过程的指针, 所以在源代码中, 必须在域被设置之前, 定义该过程的声明 否则, 编译器类型检查时会警告该行 cbclsexra 允许程序员为类结构增加额外的空间来存储只有应用程序才知道的类特定数据 cbwndextra 更加便于使用, 这个域为 Windows 内部结构增加空间, 该结构负责维护窗口每个实例的状态 不在窗口结构本身里存储大量的数据, 应用程序应该存储一个指向应用程序特定结构的指针, 该结构包含窗口每个实例的数据 在 Windows CE 里,cbClsExtra 和 cbwndextra 域必须时 4 字节的倍数 hinstance 域设置为程序的实例句柄, 该句柄指明拥有窗口的进程 hicon 域设置为窗口默认图标的句柄, 但在 Windows CE 中并不支持该域, 所以该域应该设置为 NULL ( 在 Windows CE 中, 会在类的第一个窗口被创建后设置类的图标 对于 Hello3, 没有图标提供, 并且与其它 Windows 版本不同,Windows CE 中没有任何预定义图标用于装载 ) 除非应用程序是为带鼠标的 Windows CE 系统设计的, 否则 hcursor 域应该设置为 NULL 幸运的是, 如果系统不支持光标, 调用 LoadCursor (IDC_ARROW) 函数会返回 NULL hbrbackground 域规定 Windows CE 如何画窗口背景 Windows 用这个域中指定的刷子 brush( 一个小的预定义的像素数组 ) 来画窗口背景 Windows CE 提供许多预定义的刷子, 你可以用 GetStockObject 函数来装载 如果 hbrbackground 域是 NULL, 窗口必须处理 WM_ERASEBKGND 消息, 重画窗口背景 lpszmenuname 域必须设置为 NULL, 因为 Windows CE 不直接支持有菜单的窗口 在 Windows CE 中, 菜单由主窗口创建的命令工具条 命令带或菜单条控件提供 lpszclassname 设置为程序员定义的字符串, 用于为 Windows 指明类的名字 Hello3 用的是 MyClass 做为类名 整个 WNDCLASS 类被填充后,RegisterClass 函数被调用, 并用指向 WNDCLASS 结构的指针作为唯一的参数 如果函数成功, 一个标记窗口类的值被返, 如果失败, 函数返回 0 创建窗口一旦窗口类注册成功, 就可以创建主窗口了 所有 Windows 程序员在他们的我 Windows 编程

26 生涯里都会学习到 CreateWindow 和 CreateWindowEx 函数调用 CreateWindowEx 的原型如下 : HWND CreateWindowEx (DWORD dwexstyle, LPCTSTR lpclassname, LPCTSTR lpwindowname, DWORD dwstyle, int x, int y, int nwidth, int nheight, HWND hwndparent, HMENU hmenu, HINSTANCE hinstance, LPVOID lpparam); 虽然参数数量让人畏惧, 但是一旦你了解了这些参数, 会发现它们很有逻辑性 第 1 个参数是扩展风格标志位 Windows CE 能够支持的扩展风格标志如下 : WS_EX_TOPMOST 窗口置顶 WS_EX_WINDOWEDGE 窗口有凸起的边框 WS_EX_CLIENTEDGE 窗口有凹陷的边框 WS_EX_STATICEDGE 静态窗口具有 3D 外观 WS_EX_OVERLAPPEDWINDOW 是 WS_EX_WINDOWEDGE 和 WS_EX_CLIENTEDGE 两个风格的组合 WS_EX_CAPTIONOKBUTTON 在标题栏上有 OK 按钮 WS_EX_CONTEXTHELP 在标题栏上有帮助按钮 WS_EX_NOACTIVATE 点击窗口时, 窗口不成为活动窗口 WS_EX_NOANIMATION 当窗口创建的时候, 顶层窗口没有弹出矩形, 在任务条上也没有按钮 WS_EX_NODRAG 防止窗口被移动参数 dwexstyle 是 CreateWindowEx 和 CreateWindow 之间唯一有差别的地方 实际上, 如果你在 Windows CE 头文件里看 CreateWindow 的声明, 会发现 CreateWindow 只是简单的将 dwexstyle 设置为 0 并调用 CreateWindowEx 而已 第 2 个参数是实例化窗口所使用的窗口类的名字 在 Hello3 里, 类名是 MyClass, 也就是用 RegisterClass 注册的类的名字 第 3 个参数用做窗口文本 在 Windows 其它版本里, 它是用做标准窗口标题栏里的文字 在 H/PC 里, 主窗口很少有标题栏, 这个文字只用在任务条按钮上 在 Pocket PC 里, 这个文字出现在显示屏顶部导航条里 文字使用 TEXT 宏, 确保字符串在 Windows CE 下可以转换成 Unicode 风格标志规定了窗口的初始风格 风格标志即用于系统里所有相关窗口的普通风格, 也用于特定类的风格, 比如按钮类或者列表框类的风格 在这种情况下, 我们需要指定的就是用 WS_VISIBLE 标志来指明窗口在创建时可视 经验丰富的 Win32 程序员应该查阅关于 CreateWindow 的文档, 因为许多窗口风格标志在 Windows CE 下并不支持 接下来的四个参数指定了窗口初始位置和大小 因为 Wimdows CE 下大部分应用程序都是全屏窗口, 所以每一个大小和位置域都使用 CW_USEDEFAULT 标志作为默认值 在 Windows CE 当前版本里, 默认值创建的窗口, 其大小覆盖整个屏幕 注意不要为 Windows CE 设备假设任何特殊的尺寸, 因为不同的实现有不同的屏幕尺寸 下一个域填写为父窗口的句柄 因为是顶层窗口, 所以父窗口域设置为 NULL 菜单域也设置为 NULL, 因为 Windows CE 不支持顶层窗口菜单

27 hinstance 参数就是传递给程序的实例句柄 窗口创建中实例句柄总会用的上, 实例句柄是在程序开始时就被存储的 最后的参数是一个指针, 在 WM_CREATE 消息期间, 用于在 CreateWindow 调用时传递数据给窗口过程 本例中, 没有额外数据需要传递, 所以该参数设置为 NULL 如果创建窗口成功,CreateWindow 返回刚创建的窗口的句柄, 如果函数调用期间有错误发生, 则返回 0 在通过错误检查语句--if 语句之后, 该窗口句柄用在接下来的两个语句里 (ShowWindow 和 UpdateWindow 里 ) ShowWindow 函数修改窗口状态, 使其同传给 WinMain 的参数 ncmdshow 中给的状态一致 UpdateWindow 函数则强制 Windows 发送 WM_PAINT 消息给刚创建的窗口 消息循环主窗口创建后,WinMain 进入消息循环, 这是每个 Windows 应用程序的心脏 Hello3 的消息循环定义如下 : while (GetMessage (&msg, NULL, 0, 0)) { TranslateMessage (&msg); DispatchMessage (&msg); 该循环很简单 : 调用 GetMessage 函数, 从应用程序消息队列中获取下一个消息 如果没有消息可用, 则调用进入等待期, 阻塞应用程序线程直到消息可用 当消息可用, 该函数返回包含在 MSG 结构的消息数据 MSG 结构自身包含几个域, 有的用于识别消息, 有的提供特定消息参数, 有的识别在消息被发送之前, 被笔触摸过的最后屏幕位置点 该位置信息不同于标准 Win32 消息位置数据, 在 XP 下, 返回的位置是当前鼠标位置而不是最后点击 ( 或者 tapped, 在 Windows CE 里 ) 的位置 TranslateMessage 把适当的键盘信息转换成字符信息 ( 后面会讨论其它信息过滤器, 比如 IsDialogMsg )DispatchMessage 接下来告诉 Windows 把消息发给应用程序适当的窗口 获取消息 转换消息 分发消息这个过程会一直循环到 GetMessage 收到 WM_QUIT 消息, 这会使 GetMessage 返回 0, 这一点不同于其它消息 从 while 子句可以看出,GetMessage 返回 0 将导致循环终止 消息循环终止后, 程序除了清理和退出外几乎不做什么 在 Hello3 里, 程序简单的从 WinMain 中返回 WinMain 的返回值成为程序的返回码 传统上, 最后一个消息 WM_QUIT 的 wparam 参数值包含有返回值 为了响应应用程序对 PostQuitMessage 的调用,WM_QUIT 消息被发送出去, 此时 WM_QUIT 的 wparam 参数值被填充 窗口过程发送或提交 (send 或 post 方式 ) 到 Hello3 主窗口的消息被送到 MainWndProc 过程中 和所有窗口过程一样,MainWndProc 原型如下 : LRESULT CALLBACK MainWndProc (HWND hwnd, UINT wmsg, WPARAM wparam, LPARAM lparam); 返回值类型 LRESULT 实际上就是 long 型 ( 在 Windows 里 long 是一个 32 位值 ), 写成这种形式是为源代码和机器之间提供一个中间级 虽然你可以轻易的从包含文件中确定 Windows

28 编程时使用的变量的真实类型, 但当你试图把代码做跨平台的转换时会产生问题 虽然了解变量类型的大小对计算内存使用是有用的, 但没有什么好的理由去使用 ( 实际上有很多不使用的理由 ) windows.h 文件中提供的类型定义 CALLBACK 类型指明该函数是 EXE 的外部入口点, 这是 Windows 直接调用该过程所必须的 在桌面系统里,CALLBACK 指出参数是按类 Pascal 风格从右到左方式压进程序栈的, 这和标准 C 语言方式相反 为外部入口点使用 Pascal 语言栈框架的原因可以追朔到 Windows 开发非常早的时期 使用固定大小 Pascal 栈方式, 意味着由被调用的过程来清理栈, 而不是留给调用者来清理 这种方式可以有效的减少 Windows 及其附属程序的大小, 所以早期的微软开发者认为这是一个好的方式 在 Windows CE 里, 应用程序对所有函数都使用 C 栈框架, 不管是否是外部调用 传给窗口过程的第一个参数是窗口句柄, 当您需要定义具体的窗口实例的时候, 这个句柄是很有用的 wmsg 参数表示发给窗口的消息 这不是 WinMain 消息循环里使用的 MSG 结构, 而是一个包含消息值的 unsigned 整型 剩余两个参数,wParam 和 lparam, 传递和具体消息有关的数据给窗口过程 它们的名字来自 Win16 时代, 那时 wparam 是个 16 位值而 lparam 是 32 位值 同其它 Win32 操作系统一样, 在 Windows CE 里, 两个都是 32 位的 和传统的窗口过程一样,Hello3 的窗口过程通过一个 switch 语句解析 wmsg 消息 ID 该 switch 语句包含 2 个 case 语句, 一个用来解析 WM_PAINT 消息, 另一个用来解析 WM_DESTROY 消息 这个窗口过程大概是窗口过程所能简化到及至的一个窗口过程了 WM_PAINT 绘制窗口, 处理 WM_PAINT 消息, 这在任何 Windows 程序中都是很重要的功能之一 窗口的外观是在程序处理 WM_PAINT 消息的过程中完成的 除了用您在注册窗口类时指定的刷子绘制默认背景外,Windows 对处理该消息不提供任何帮助 Hello3 中处理 WM_PAINT 消息如下 : case WM_PAINT: Get the size of the client rectangle GetClientRect (hwnd, &rect); hdc = BeginPaint (hwnd, &ps); DrawText (hdc, TEXT ("Hello Windows CE!"), -1, &rect, DT_CENTER DT_VCENTER DT_SINGLELINE); EndPaint (hwnd, &ps); return 0; 在窗口绘制之前, 程序必须确定窗口大小 在 Windows 程序里, 一个标准窗口被划分为两个区域 -- 非客户区和客户区 窗口标题栏和可变大小的边框通常占据了窗口的非客户区, 这个区域由 Windows 负责绘制 客户区属于窗口的内部区域, 由应用程序负责绘制 应用程序通过调用 GetClientRect 函数来确定客户区的大小和位置 该函数返回一个 RECT 结构, 包含左上角 右下角坐标等描述客户区矩形边界的信息 分成客户区和非客户区的好处是, 应用程序不必绘制那些窗口标准元素, 例如标题栏 其它版本的 Windows 提供一系列 WM_NCxxx 消息, 允许您的应用程序绘制非客户区 在 Windows CE 里, 窗口很少有标题栏 因为很少有非客户区, 所以 Windows CE 不发送非客户端消息给窗口过程

29 WM_PAINT 消息里执行的所有绘制工作都必须由两个函数 BeginPaint 和 EndPaint 包围 BeginPaint 函数返回设备环境句柄 HDC 设备环境是物理显示设备( 例如视频显示器或打印机 ) 的逻辑代表 Windows 程序从不直接修改显示硬件 相反,Windows 用设备环境将程序与具体硬件隔离开 BeginPaint 填充一个 PAINTSTRUCT 结构, 其结构如下 : typedef struct tagpaintstruct { HDC hdc; BOOL ferase; RECT rcpaint; BOOL frestore; BOOL fincupdate; BYTE rgbreserved[32]; PAINTSTRUCT; hdc 就是 BeginPaint 函数返回的句柄 ferase 指出窗口过程是否需要重画窗口背景 rcpaint 是 RECT 结构, 定义了需要重画的客户区 Hello3 忽略该域, 并假设在每个 WM_PAINT 消息中, 整个客户区窗口都需要重画 当性能是需要考虑的问题时, 该域是很有用的, 因为有时仅仅需要重画部分窗口即可 即使当程序尝试重画 rcpaint 矩形以外的区域时,Windows 也会阻止这么做的 该结构的其它域,fRestore, fincupdate, 和 rgbreserved, 属于 Windows 内部使用, 应用程序可以忽略掉它们 Hello3 中唯一的绘制工作是在窗口绘制一行文本 Hello3 调用 DrawText 函数来完成该绘制 我将在第 2 章描述 DrawText 的细节, 如果您看一下该函数, 很容易会明白这个调用在窗口上绘制了一行字符串 Hello Windows CE 在 DrawText 返回后, 调用 EndPaint 来通知 Windows 程序已经完成了窗口更新 EndPaint 调用同时也使没有被绘制的窗口其它区域有效 Windows 保持一份无效窗口区域 ( 也就是需要重画的区域 ) 列表和有效区域 ( 也就是已经更新的区域 ) 列表 不论您是否在窗口画了什么, 通过成对的调用 BeginPaint 和 EndPaint, 会通知 Windows 由您来处理窗口的无效区域 实际上, 您必须调用 BeginPaint 和 EndPaint, 或者通过其它方式使窗口无效区域变有效, 否则 Windows 会不断发送 WM_PAINT 消息给窗口, 直到无效区域变有效 WM_DESTROY Hello3 中处理的另一个消息是 WM_DESTROY 当窗口即将被销毁时, 该消息被送出 因为该窗口是应用程序主窗口, 当窗口被销毁时应用程序将终止 处理 WM_DESTROY 消息的代码调用 PostQuitMessage 消息来触发该动作 PostQuitMessage 函数将 WM_QUIT 消息放到到消息队列里 该函数的参数是返回码的值, 该值放在 WM_QUIT 消息的 wparam 参数里传回应用程序 如前所述, 消息循环看到 WM_QUIT 消息就会退出循环 WinMain 接着调用 TermInstance, 在 Hello3 里, 该函数什么也不做, 只是返回 WinMain 接着返回, 并终止程序 Hello3 是典型的 Windows 程序 这种编程风格有时也成为 Petzold 式 Windows 编程, 这是为了向 Charles Petzold, 这位 Windows 编程大师表示敬意 Charles 所著的 Windows 程序设计 (Programming Microsoft Windows ) 当前是第 5 版, 并且依然是学习 Windows 编程的最好的书

30 我更喜欢为我的 Windows 程序选择略微不同的设计 从某种意义上讲, 这是一个将 Windows 程序功能组件化的方法, 这使的更加容易将程序的一部分复制到另一个程序 在本章最终的例子 里, 我介绍这种编程风格, 并一起介绍一些 Windows CE 应用程序所必须的额外特性 WinCE 程序设计 (3rd 版 )--1.7 HelloCE HelloCE Windows 编程中典型的 SDK 风格饱受责难的地方就是在窗口过程中总是使用巨大的 switch 语句 switch 语句分析传给窗口过程的消息, 这样每个消息可以被独立的处理 这种标准结果的优势之一是强制把一个类似的结构加到几乎所有 Windows 应用程序中, 这使一个程序员可以更容易理解另一个人的代码 劣势是整个窗口过程的所有的变量通常会比较杂乱的出现在过程的开头 这么多年来, 我为我的 Windows 程序探索出一个不同的风格 主要想法是将 WinMain 和 WinProc 过程分解成更易理解和更易转换到其它 Windows 程序中的可管理单元 WinMain 被分解成几个过程, 包括执行应用程序初始化 实例初始化和实例终止 作为所有 Windows 程序核心的消息循环也在 WinMain 里 窗口过程被分解为几个独立过程, 每个处理一个具体的消息 窗口过程自身是一个代码框架, 只是查找传入的消息, 看是否有过程来处理这个消息 如果有, 则调用该过程 ; 如果没有, 则把消息传递给默认的窗口过程 把对消息的处理划分成独立的块, 使该结构更容易被理解 并且, 由于将一个消息处理代码段同另一个极大的隔离开来, 可以使您更容易把处理特定消息的代码从一个程序转换到另一个程序 还是在很多年前, 我从 Ray Duncan 在 PC 杂志 的 编程力量 专栏里, 第一次看到对这种结构的描述 在 MS-DOS 和 OS/2 编程领域里,Ray 是传奇人物之一 虽然为了适合我的需要, 我对这种设计做了一些修改, 但这还是应该归功于 Ray 代码 HelloCE 的源代码如清单 1-4 所示 : 清单 1-4 HelloCE 程序 HelloCE.h ================================================= ===================== Header file Written for the book Programming Windows CE Copyright (C) 2003 Douglas Boling ================================================= =============== Returns number of elements #define dim(x) (sizeof(x) / sizeof(x[0])) Generic defines and data types

31 struct decodeuint { Structure associates UINT Code; messages with a function. LRESULT (*Fxn)(HWND, UINT, WPARAM, LPARAM); ; struct decodecmd { Structure associates UINT Code; menu IDs with a LRESULT (*Fxn)(HWND, WORD, HWND, WORD); function ; Function prototypes HWND InitInstance (HINSTANCE, LPWSTR, int); int TermInstance (HINSTANCE, int); Window procedures LRESULT CALLBACK MainWndProc (HWND, UINT, WPARAM, LPARAM); Message handlers LRESULT DoPaintMain (HWND, UINT, WPARAM, LPARAM); LRESULT DoDestroyMain (HWND, UINT, WPARAM, LPARAM); ================================================= ===================== HelloCE - A simple application for Windows CE Written for the book Programming Windows CE Copyright (C) 2003 Douglas Boling ================================================= ===================== #include <windows.h> For all that Windows stuff #include "helloce.h" Program-specific stuff Global data const TCHAR szappname[] = TEXT("HelloCE"); HINSTANCE hinst; Program instance handle Message dispatch table for MainWindowProc const struct decodeuint MainMessages[] = { WM_PAINT, DoPaintMain, WM_DESTROY, DoDestroyMain,

32 ; ================================================= ===================== Program entry point int WINAPI WinMain (HINSTANCE hinstance, HINSTANCE hprevinstance, LPWSTR lpcmdline, int ncmdshow) { MSG msg; int rc = 0; HWND hwndmain; Initialize this instance. hwndmain = InitInstance (hinstance, lpcmdline, ncmdshow); if (hwndmain == 0) return 0x10; Application message loop while (GetMessage (&msg, NULL, 0, 0)) { TranslateMessage (&msg); DispatchMessage (&msg); Instance cleanup return TermInstance (hinstance, msg.wparam); InitInstance - Instance initialization HWND InitInstance (HINSTANCE hinstance, LPWSTR lpcmdline, int ncmdshow) { WNDCLASS wc; HWND hwnd; Save program instance handle in global variable. hinst = hinstance; #if defined(win32_platform_pspc) If Pocket PC, only allow one instance of the application hwnd = FindWindow (szappname, NULL); if (hwnd) { SetForegroundWindow ((HWND)(((DWORD)hWnd) 0x01)); return 0; #endif Register application main window class.

33 wc.style = 0; Window style wc.lpfnwndproc = MainWndProc; Callback function wc.cbclsextra = 0; Extra class data wc.cbwndextra = 0; Extra window data wc.hinstance = hinstance; Owner handle wc.hicon = NULL, Application icon wc.hcursor = LoadCursor (NULL, IDC_ARROW); Default cursor wc.hbrbackground = (HBRUSH) GetStockObject (WHITE_BRUSH); wc.lpszmenuname = NULL; Menu name wc.lpszclassname = szappname; Window class name if (RegisterClass (&wc) == 0) return 0; Create main window. hwnd = CreateWindow (szappname, Window class TEXT("HelloCE"), Window title Style flags WS_VISIBLE WS_CAPTION WS_SYSMENU, CW_USEDEFAULT, x position CW_USEDEFAULT, y position CW_USEDEFAULT, Initial width CW_USEDEFAULT, Initial height NULL, Parent NULL, Menu, must be null hinstance, Application instance NULL); Pointer to create parameters if (!IsWindow (hwnd)) return 0; Fail code if not created. Standard show and update calls ShowWindow (hwnd, ncmdshow); UpdateWindow (hwnd); return hwnd; TermInstance - Program cleanup int TermInstance (HINSTANCE hinstance, int ndefrc) { return ndefrc; ================================================= ===================== Message handling procedures for main window

34 MainWndProc - Callback function for application window LRESULT CALLBACK MainWndProc (HWND hwnd, UINT wmsg, WPARAM wparam, LPARAM lparam) { INT i; Search message list to see if we need to handle this message. If in list, call procedure. for (i = 0; i < dim(mainmessages); i++) { if (wmsg == MainMessages[i].Code) return (*MainMessages[i].Fxn)(hWnd, wmsg, wparam, lparam); return DefWindowProc (hwnd, wmsg, wparam, lparam); DoPaintMain - Process WM_PAINT message for window. LRESULT DoPaintMain (HWND hwnd, UINT wmsg, WPARAM wparam, LPARAM lparam) { PAINTSTRUCT ps; RECT rect; HDC hdc; Get the size of the client rectangle GetClientRect (hwnd, &rect); hdc = BeginPaint (hwnd, &ps); DrawText (hdc, TEXT ("Hello Windows CE!"), -1, &rect, DT_CENTER DT_VCENTER DT_SINGLELINE); EndPaint (hwnd, &ps); return 0; DoDestroyMain - Process WM_DESTROY message for window. LRESULT DoDestroyMain (HWND hwnd, UINT wmsg, WPARAM wparam, LPARAM lparam) { PostQuitMessage (0); return 0;

35 如果您浏览 HelloCE 的源代码, 会从中看到本书中所有程序都使用的标准模板 在包含的头文件和宏定义之后是一些全局变量 我知道有很多好的建议劝说全局变量不应该出现在程序里, 但我使用他们是为了便于简化本书中的例子, 并使它们更条理清晰 每个程序都定义了一个 Unicode 字符串 szappname, 它用在程序的很多地方 hinst 也同样用在很多地方, 并且在详述 InitInstance 过程时, 我会提到它 最后那个全局结构是一个消息列表, 包含处理相关消息的过程 窗口过程使用这个结构将消息及处理消息的过程关联到一起 HelloCE 中,WinMain 有两各基本功能 : 调用 InitInstance( 放有应用程序初始化的代码 ), 在消息循环中处理消息, 当消息循环退出时调用 TerminateInstance 在这个程序模版里, WinMain 成为一个基本不用修改的例程 总的来说,WinMain 唯一的改变之处是对消息循环处理过程的修改, 涉及对键盘加速键的处理以及对无模式对话框消息及其他任务的监控 实例初始化 InitInstance 的主要任务是注册主窗口的窗口类, 创建应用程序主窗口, 按传给 WinMain 的 ncmdshow 参数指定的格式显示主窗口 如果是为 Pocket PC 编译, 则还有一些条件编译代码, 用来防止同一时刻运行一个程序的多个实例 InitInstance 做的第一个工作就是把程序实例句柄 hinstance 保存在全局变量 hinst 中 程序的实例句柄在 Windows 应用程序的很多地方是很有用的 我之所以在这里保存这个值是因为此时已经知道实例句柄并且这是程序中保存实例句柄的一个很方便的地方 当在 Pocket PC 上运行时,HelloCE 用 FindWindow 来查看是否有自身的副本正在运行 该函数在顶层窗口中搜索, 看是否有类名或窗口标题匹配或者两者都匹配的窗口 如果找到匹配的, 用 SetFroegroundWindow 函数将窗口放到最前面, 之后该例程退出, 返回码为 0, 这将使 WinMain 退出, 终止应用程序 我将花更多的时间在 17 章里讨 Pocket PC 相关的代码 Pocket PC 相关的代码包含在 #if and #endif 行里 这些行告诉编译器只有当 #if 语句的条件为真的时候才包含它们, 在本例中, 如果定义了常量 WIN32_PLATFORM_PSPC, 则条件为真 该常量定义在 [ 项目设置 ] 中 快速浏览一下 [ 项目设置 ] 中的 C/C++ 页, 可以看到完整的关于预处理器定义的区域 在这个区域里, 定义之一是 $(CePlatform-Ce 平台 ),$ 注册值占位符 在 Key [HKEY_LOCAL_MACHINE]\Software\Microsoft\Windows CE Tools\Platform Manager 里, 你可以找到一系列注册 key, 每个代表一个在 evc++ 中安装的目标平台 CePlatform(Ce 平台 ) 值取决于目标项目的不同 对 Pocket PC 和老式 Palm-size PC 项目, CePlatform 定义为 WIN32_PLATFORM_PSPC 窗口类的注册和主窗口的创建过程与 Hello3 中的过程很相似 唯一的不同是使用了用做主窗口类类名的全局字符串 szappname 每次我用这个模板, 我将 szappname 改成程序的名字即可 这可以使不同的应用程序窗口类名保持唯一, 方便 FindWindow 工作 到此 InitInstance 算是完成了, 应用程序主窗口已经创建和更新了, 因为在进入消息循环之前, 已经有消息发送给窗口的窗口过程了 现在是时候看看这部分程序了 窗口过程当你写 Windows 程序的时候, 编程的大部分时间是花在窗口过程上的 窗口过程是程序的核心, 也是窗口行为创建程序个性的地方 同大部分不使用 MFC 等类库的 Windows 程序相比, 我的编程风格明显不同的地方正是在窗口过程里 对于我的几乎所有程序, 窗口过程都和前面 HelloCE 里的一样 在进一步深入之前,

36 我重申 : 这种程序结构并不特别用在 Windows CE 中 我的所有 Windows 应用程序都使用这种风格, 不管是 Windows 3.1 Me XP, 还是 CE 这种风格将窗口构成简化成一个简单的表查找函数 主要思想是在早先定义在 C 文件里的 MainMessages 表里查找消息值 如果消息被找到, 关联的过程就被调用, 并把原始参数传递给处理该消息的过程 如果没有找到, 调用默认过程 DefWindowProc DefWindowProc 是 Windows 函数, 为系统里所有消息提供默认行为, 这使得 Windows 程序不用处理传递给窗口的每个消息 消息表将消息值和处理消息的过程关联在一起 该表如下所示 : Message dispatch table for MainWindowProc const struct decodeuint MainMessages[] = { WM_PAINT, DoPaintMain, WM_DESTROY, DoDestroyMain, ; 该表定义为常量, 这不仅仅是好的编程习惯, 而且因为这样可以帮助节约内存 因为 Windows CE 程序可以在 ROM 里执行, 不变的数据应该标记为常量 这样允许 Windows CE 程序装载器将常量数据放在 ROM 里, 而不是装载一个副本到 RAM 里, 因此节约了宝贵的 RAM 表自身是一个简单的结构数组, 该结构包含 2 个原素 第一项是消息值, 第二项是指向处理消息的函数的指针 因为函数可以起任何名字, 所以在整本书里我使用了一致的结构, 好帮助您理解它们 名字由 Do 前缀 ( 符合面向对象的经验 ), 后跟一个消息名及一个用来指明与表相关的窗口类的后缀 例如 DoPaintMain 是为程序的主窗口处理 Wm_PAINT 消息的函数名 DoPaintMain 和 DoDestroyMain HelloCE 里两个消息处理例程是 PaintMain 和 DoDestroyMain 它们和 Hello3 里 case 子句的功能很类似 独立例程的好处是代码和本地局部变量是例程隔离的 而在 Hello3 的窗口过程里, 针对绘画代码的局部变量则都集中在窗口过程的顶部 代码的封装使您很容易复制代码到您的下一个应用程序里 运行 HelloCE 当在 evc++ 中输入和编译本程序后, 可以在 VC++ 里选择 [Build]->[Execute] HelloCE.exe 或者按 Ctrl+F5 远程执行本程序 程序在空白窗口的中间显示一行 "Hello Windows CE" 字样, 图 1-3 和图 1-4 显示了 HelloCE 运行在 PocketPC 上的样子 点一下标题栏上的 [Close] 按钮会让 Windwos CE 给窗口发送 WM_CLOSE 消息 虽然 HelloCE 没有明确的处理 WM_CLOSE 消息, 但 DefWindowProc 过程使用销毁主窗口作为默认的处理方式 因为窗口正在销毁, 会发出 WM_DESTORY 消息, 这又会导致对 PostQuitMessage 的调用 图 1-3( 略 ) 运行在嵌入式 Windows CE 系统上的 HelloCE 窗口 正象我说过的,HelloCE 是一个非常基本的 Windows CE 程序, 但它给您展示了一个应用程序基本框架, 您可以在上面添加更多内容 如果您用浏览器看 HelloCE.exe 文件, 会发现该程序使用的是通用图标 当 HelloCE 运行的时候, 任务条上 HelloCE 对应的按钮里, 文字旁边也没有图标 关于给程序增加定制图标以及 DrawText 函数是如何工作的, 我将在后面几章作为两个主题来讲解 图 1-4( 略 ) 运行在 Pocket PC 上的 HelloCE 窗口

37 图 1-4 显示了 HelloCE 在 Pocket PC 上运行时的问题 HelloCE 窗口伸展到了屏幕底部 和程序间具体切换方式有关,SIP( 输入法软键盘 ) 按钮可能显示在 HelloCE 窗口的上面 为 Pocket PC 设计的应用程序会在屏幕底部创建一个菜单条, 用来显示软键盘等事物的按钮会包含在上面 必须人工调整窗口尺寸, 避免覆盖菜单条或者被菜单条覆盖 稍后我们会讨论如何为 Pocket PC 的用户界面设计应用程序 可以确信的是 : 书中头几章关于 Windows CE 的内容一样适用于 Pocket PC 设备及其它 Windows CE 系统 WinCE 程序设计 (3rd 版 )-- 第 2 章屏幕绘图 -- 概述 第 2 章屏幕绘图概述 在第 1 章, 示例程序 HelloCE 完成一项工作 : 在屏幕上显示一行文字 显示这行文字只需要调 用一次 DrawText 即可, 因为 Windows CE 代为处理了很多细节, 例如字体 字体颜色 文本 行在屏幕上的位置等等 借助图形用户接口的力量, 应用程序不只能在屏幕上输出本文行, 还能 做更多的事情 应用程序可以绘制出非常精细的显示外观 纵观微软 Windows 操作系统, 用于绘制屏幕的函数数量发生了巨大的扩展 Windows 每个后 续的版本里, 都增加了许多函数以扩展程序员可以使用的工具集 虽然新函数增加了, 但旧函数 依然被保留, 这样即使有旧函数被新函数取代, 旧程序依然可以继续运行在新版本的 Windows 上 这种函数不断堆积, 旧函数被保留以向后兼容的策略, 在最初的 Windows CE 版本里却被 废弃了 因为需要制作更小版本的 Windows,CE 团队苦览 Win32 API, 并只复制适合 Windwos CE 目标市场的应用程序绝对需要的 API 这种精简对 Win32 API 影响最大的领域之一就是图形函数 到不是您会缺乏用于工作的函数, 只是在 Win32 API 的冗余度方面, 对图形函数做了教大的精简 程序员面临的新挑战之一就是 不同的 Windows CE 平台支持略微不同的 API 集合 Windows CE 图形功能与桌面系统不同 之处, 其中之一就是 Windows CE 不支持不同的映射模式, 而这在其他 Windows 系统里是支 持的 Windows CE 设备环境始终设置为 MM_TEXT 映射模式 坐标转化在 Windows CE 下 也不支持 虽然这些特性在一些类型的应用中很有用, 但在小型便携式设备的 Windows CE 环 境里, 这些需求并不突出 所以当你阅读本章里使用的函数和技术时, 请记住其中一些可能不能 在所有平台上被支持 通过 GetDeviceCaps 函数, 程序可以判断系统支持什么函数 GetDeviceCaps 返回当前图形设备的实际能力 贯穿本章始末, 当判定在目标设备上什么函 数被支持时, 我会谈到 GetDeviceCaps 函数的 像书中第一部分里其它章节一样, 本章回顾 Windows CE 所支持的绘画功能 需要记住的最重 要的事情之一是虽然 Windows CE 不支持全部 Win32 图形 API, 但它的快速发展使它可以支 持一些 Win32 里最新的函数 -- 其中一些非常新, 可能您对它们都不熟悉 本章将为您展示您可 以使用的函数以及如何在这个有一些函数不被 Windows CE 支持的领域里工作 WinCE 程序设计 (3rd 版 )--2.1 绘图基础 绘图基础综观历史,Windows 被细分成三个主要部分 : 核心层, 处理进程和管理内存 ; 用户层, 处理窗 口接口和控件 ; 图形设备接口 (GDI) 负责底层绘制 在 Windows CE 里, 用户层和 GDI 层 合成为图形窗口及事件处理器, 即 GWE 你可能有时会听 Windows CE 程序员谈起 GWE

38 GWE 并不是什么新事务, 只是标准 Windows 部件的不同包装而已 在本书里, 我通常将 GWE 的图形部分依然称为 GDI, 以保持和标准 Windows 编程术语的一致性 不论你是为 Windows CE 2000 还是 XP 编写程序, 需要做的不仅仅是处理 WM_PAINT 消息这么简单 理解什么时候和为什么 WM_PAINT 消息要被送到窗口是很有益处的 有效和无效区域某些情况下, 窗口的一部分暴露给用户, 这些部分在 Windows 里称为区域, 这些区域被标记为无效 当应用程序消息队列里没有其它消息在等待处理并且应用程序窗口包含有无效区域的时候,Windows 会给窗口发送 WM_PAINT 消息 正如第一章里提到的, 处理 WM_PAINT 消息的绘制操作是包含在 BeginPaint 和 EndPaint 调用之间的 BeginPaint 实际上执行很多动作 首先将无效区域标记为有效, 接下来计算需要裁减的区域 裁减区是限制绘图动作的区域 BeginPaint 接下来发送 WM_ERASEBACKGROUND 消息, 如果需要, 还会重绘背景, 如果用于指示文本输入的光标可见, 它还会隐藏光标 最后 BeginPaint 获得显示设备环境变量的句柄, 该句柄可以用于应用程序中 EndPaint 函数则释放设备环境, 如果必要, 还会重新显示光标 如果 WM_PAINT 处理过程没有更多的操作要执行, 您也必须至少调用 BeginPaint 和 EndPaint, 以便将无效区域标记为有效 作为替代, 您可以调用 ValidateRect 来强制使矩形有效 但这种情况下没有绘制动作发生, 因为应用程序在窗口上绘制任何东西之前, 必须有设备环境句柄 应用程序经常需要强制重画它的窗口 应用程序决不应该邮递或发送 (post or send) WM_PAINT 消息给自身或其它窗口 您应该使用以下函数 : BOOL InvalidateRect (HWND hwnd, const RECT *lprect, BOOL berase); 请注意 InvalidateRect 并不要求窗口设备环境句柄, 只要窗口句柄自身 lprect 表示窗口中需要无效的区域 该参数为 NULL 则表示整个窗口无效 berase 用来指出在调用 BeginPaint 的时候是否重画窗口背景 请注意不像 Windows 的其它版本,Windows CE 要求 hwnd 必须是一个有效的窗口句柄 设备环境设备环境经常被简称为 DC, 它被 Windows 用于管理对显示器和打印机的访问, 当然在本章我将只讨论显示器 除非特别说明, 下面的讨论适合所有 Windows, 而并不具体针对 Windows CE Windows 应用程序从不直接写屏幕 相反, 它们为适当的窗口请求一个显示设备环境句柄, 之后用该句柄在设备环境里绘制 接下来 Windows 作为中间人将像素从 DC 操纵到屏幕上 只应该在 WM_PAINT 消息里调用 BeginPaint, 它为窗口返回一个显示 DC 句柄 通常应用程序在处理 WM_PAINT 消息时在屏幕上绘制东西 Windows 将绘制作为一个低优先级的任务, 这样做是适当的, 因为将绘制作为高优先级会导致为每个小的显示改变都产生一个绘图消息, 这将使绘图消息泛滥 而通过处理所有正在等待的消息, 允许应用程序先完成所有未完成的事务, 这样使所有无效区域能够被有效的一次性绘制完成 用户并不会注意到由 WM_PAINT 消息低优先级所带来的微小延迟 当然, 有些时候是需要立即绘制的 字处理器就是一个例子, 当键盘被按下后, 字处理器需要立即显示对应的字符 为了在 WM_PAINT 消息以外的时刻进行绘制, 可以用 GetDC 函数来获得 DC 句柄 GetDC 原型如下 :HDC GetDC (HWND hwnd);

39 GetDC 返回窗口客户区 DC 句柄 接下来可以在窗口客户区的任何地方进行绘制, 因为这个过程不像 WM_PAINT 消息的处理过程, 没有裁减区域来限制您只能在一个无效区域里绘制 Windows CE 支持另一个获得 DC 的函数, 该函数如下 : HDC GetDCEx (HWND hwnd, HRGN hrgnclip, DWORD flags); GetDCEx 允许您对返回的设备环境有更多的控制 新参数 hrgnclip 使您可以定义用来限制绘制区域的裁减区域 flags 指出当您在 DC 上绘制的时候,DC 如何反应 注意 Windows CE 不支持下面的标志 :DCX_PARENTCLIP, DCX_NORESETATTRS, DCX_LOCKWINDOWUPDATE, 和 DCX_VALIDATE 当绘制完成后, 必须调用 ReleaseDC 来释放设备环境 ReleaseDC 原型如下 : int ReleaseDC (HWND hwnd, HDC hdc); GetDC 用于在客户区内绘制, 有时应用程序需要访问窗口非客户区, 比如标题栏 为了获得整个窗口的 DC, 使用以下函数 :HDC GetWindowDC (HWND hwnd); 如前所述, 当绘制完成后, 要调用 ReleaseDC Windows CE 下的 DC 函数同 XP 下的设备环境函数是一样的 这是可以预料到的, 因为 DC 是 Windows 绘图体系里的核心 对这个领域的 API 进行改变将导致 Windows CE 程序与它的桌面程序严重的不兼容 WinCE 程序设计 (3rd 版 )--2.2 输出文本输出文本在第一章里, 例子程序 HelloCE 调用 DrawText 函数显示了一行文本 代码如下 : DrawText (hdc, TEXT ("Hello Windows CE!"), -1, &rect, DT_CENTER DT_VCENTER DT_SINGLELINE); DrawText 是一个相当高级的函数, 允许由程序显示文本, 而由 Windows 处理大部分细节 DrawText 的头几个参数几乎是不言而喻, 很直观 当前正在使用的设备环境句柄被传入, 同时传入的还有被 TEXT 宏包围的用来显示的文本, 声明成 Unicode 字符串是为了符合 Windows CE 的需要 第三个参数是要输出的字符个数, 当为 -1, 则表示传入的是以 NULL 为终止符的字符串并由 Windows 计算其长度 第四个参数是一个指向 rect 结构的指针, 为文本规定了格式化矩形 DrawText 用该矩形作为文本格式化输出的基础 文本如何格式化取决于函数的最后一个参数 -- 格式化标志位 这些标志位指定文本如何被放在格式化的矩形里 在指定了 DT_CALCRECT 标志位的情况下, 由 DrawText 来计算需要输出的文本的尺寸 DrawText 甚至用自动计算出的行中断 (line break) 来将文本格式化多行 在 HelloCE 的情况里, 标志位规定文本应该水平居中 (DT_CENTER) 和垂直居中 (DT_VCENTER) DT_VCENTER 标志只在单行文本的情况下有效, 所以最后一个标志位 DT_SINGLELINE 规定如果矩形宽度不足以显示整个字符串时, 文本不应该折成多行 画文本的另一个方法就是使用下面的函数 : BOOL ExtTextOut (HDC hdc, int X, int Y, UINT fuoptions, const RECT *lprc, LPCTSTR lpstring, UINT cbcount, const int *lpdx);