友情提示:如果本网页打开太慢或显示不完整,请尝试鼠标右键“刷新”本网页!
富士康小说网 返回本书目录 加入书签 我的书架 我的书签 TXT全本下载 『收藏到我的浏览器』

深入浅出MFC第2版(PDF格式)-第7部分

快捷操作: 按键盘上方向键 ← 或 → 可快速上下翻页 按键盘上的 Enter 键可回到本书目录页 按键盘上方向键 ↑ 可回到本页顶部! 如果本书没有阅读完,想下次继续接着阅读,可使用上方 "收藏到我的浏览器" 功能 和 "加入书签" 功能!





              ■   Top 范例程序(第15 章):示范如何量身定做一个属于自己的AppWizard 。 



                我的这个Top Studio AppWizard 架在系统的MFC AppWizard 之上,增加一个 



                开发步骤,询问程序员名称及其简单声明,然后就会在每一个产生出来的原始 



                码文件最前端加上一段固定格式的说明文字。 



              ■   Test 范例程序(第16 章):此程序示范使用ponent Gallery 中的三 



                个ponents :Splash Screen、SysInfo、Tip Of The Day 。 



              ■  OcxTest 范例程序(第16 章):此程序示范使用ponent Gallery 中的Grid 



                ActiveX control 。 



38 


…………………………………………………………Page 61……………………………………………………………

                                              第0章    你定要知道(導讀) 



与前版本之差异 



  深入浅出MFC 第二版与前一版本之重大差异在于: 



  1。 软件工具由Visual C++ 4。0 改为Visual C++ 5。0 ,影响所及,第4章「Visual C++ 



    整合性软件开发环境」之内容改变极大。全书之中有关于MFC  内部动作逻 



    辑及其源代码的变动不多,因为Visual C++ 5。0  中的MFC 版本还维持在4。2 。 



  2。 第1章增加Console 程序设计,以及Win32 多线程程序实例Mltithrd 。 



  3。 第2章增加「四种不同的对象生存方式」一节。 



  4。 第3章去除原有之Frame5 程序(该程序以MFC 2。5  的技术仿真Dynamic 



    Creation )。 



  5。 第4章全部改为Visual C++ 5。0 使用画面,并在最后增加一节「Console 程序 



    的项目管理」。 



  6。 第6章增加「奇怪的窗口类别名称Afx:x:y:z:w 」一节,以及增加Hello 程序 



    对idle time  的处理。 



  7。 增加14~16 三章。 



  8。 附录A增加  的「MFC  四大天王」一文。 



  9。 附录D由原先之「OWL 程序设计一览」,改为「以MFC 重建DBWIN 」。 



  本书第一版之Scribble 程序自step1  (加了CStroke)之后,即无法在Visual C++ 4。2 和 



  Visual C++ 5。0 上顺利编译。原因出在VC++ 4。2 和VC++ 5。0 似乎未能支持〃forward 



  declaration of data structure class〃 (但是我怀疑VC++ 怎么会走退步?是不是有什么选项 



  可以设定)。无论如何,只要将CStroke 的声明搬移到SCRIBBLEDOC。H 的最前面, 



  然后再接续CScribbleDoc 的声明,即可顺利编译。请阅读本书第8章「CScribbleDoc 的 



  修改」一节之中于SCRIBBLEDOC。H 源代码列表后的一段说明(#477 页)。 



                                                                        39 


…………………………………………………………Page 62……………………………………………………………

              深入湷觥 FC 



            如何联络作者 



              我非常乐意和本书的所有读者沟通,接受您对本书以及对我的指正和建议。请将沟通内 



              容局限在对书籍、对知识的看法,以及对本书误谬之指正和建议上面,请勿要求我为您 



              解决技术问题(例如您的程序臭虫或您的项目瓶颈)。如果只是单纯地想和我交个朋友 



              聊聊天,我更倍感荣幸。 



              我的Email 地址是jjhou@ccca。nctu。edu。tw 



              我的永久通讯址是新竹市建中一路39 号13 楼之二(FAX :03…5733976 ) 



40 


…………………………………………………………Page 63……………………………………………………………

                                        1 



        勿在浮砂筑高台 



深入湷觥FC 

                2nd Edition 



                                             1 


…………………………………………………………Page 64……………………………………………………………

          第篇  勿在浮砂築高台  



2 


…………………………………………………………Page 65……………………………………………………………

第 1章 



             Win32 基本程序观念 



程序设计领域里,每一个人都想飞。 



但是,还没学会走之前,连跑都别想! 



虽然这是一本深入讲解MFC 程序设计的书,我仍坚持要安排这第一章,介绍Win32  的 



基本程序设计原理(也就是所谓的SDK 程序设计原理)。 



                    event driven                 message based 

从来不曾学习过在「事件驱动(              )系统」中撰写「以消息为基础(               ) 



之应用程序」者,能否一步跨入MFC 领域,直接以application framework 开发Windows 



                          MFC           application framework 

程序,我一直抱持怀疑的态度。虽然有了            (或任何其它的                ), 



你可以继承一整组类别,从而快速得到一个颇具规模的程序,但是Windows 程序的运作 



本质(Message Based,Event Driven )从来不曾也不会改变。如果你不能了解其髓,空有 



其皮其肉或其骨,是不可能有所精进的,即使能够操控wizard ,充其量却也只是个puppet , 



对于手上的程序代码,没有自主权。 



我认为学习MFC 之前,必要的基础是,对于Windows 程序的事件驱动特性的了解(包 



括消息的产生、获得、分派、判断、处理),以及对C++  多态(polymorphism )的精确 



体会。本章所提出的,是我对第一项必要基础的探讨,你可以从中获得关于Windows 程 



序的诞生与死亡,以及多任务环境下程序之间共存的观念。至于第二项基础,将由第二章 



为你夯实。 



                                                             3 


…………………………………………………………Page 66……………………………………………………………

让我再强调一遍,本章就是我认为Windows 程序设计者一定要知道的基础知识。一个 



连这些基础都不清楚的人,不能要求自己冒冒然就开始用Visual C++ 、用MFC、用对象 



导向的方式去设计一个你根本就不懂其运作原理的程序。 



还没学会走之前,不要跑! 



                        Dialog Editor            Image Editor              Font Editor 



                            。DLG           。BMP       。ICO       。CUR          。FON 

                                            。BMP       。ICO       。CUR         。FON 



                              。C          。H          。RC                RC piler 



                         C piler                                           。RES 

                                                                               。RES 



                                               。DEF 

                                                                            CvtRes 

                            。OBJ 

                             。OBJ 



        tool                                                                  RBJ 

                                                                               RBJ 

                            。LIB 

                             。LIB 

        text file 

                         C runtime;                                  曾经有的程序,现已不需要 

                          C runtime; 

                         DLL Import;         LINKER 

                          DLL Import; 

        binary file                                               。EXE 

                                                                   。EXE 



                    图 1…1 一个32位Windows SDK 程序的开发流程 



                                                                                           4 


…………………………………………………………Page 67……………………………………………………………

Win32 程序开发流程 



     Windows                   UI User Interface                    RC 

            程序分为「程序代码」和「          (         )资源」两大部份,两部份最后以 



                       EXE     图          UI  

     编译器整合为一个完整的           文件(   1…1)。所谓    资源是指功能菜单、对话框 



     外貌、程序图标、光标形状等等东西。这些UI 资源的实际内容(二进制代码)系借助各 



     种工具产生,并以各种扩展名存在,如。ico、。bmp 、。cur 等等。程序员必须在一个所谓 



                 。rc         RC       RC。EXE     RC             UI 

     的资源描述档(      )中描述它们。       编译器(        )读取    档的描述后将所有 



     资源档集中制作出一个。RES 档,再与程序代码结合在一起,这才是一个完整的Windows 



     可执行档。 



                        。LIB 

 需要什么函数库 (                   ) 



     众所周知Windows 支持动态联结。换句话说,应用程序所调用的Windows API 函数是 



     在「执行时期」才联结上的。那么,「联结时期」所需的函数库做什么用?有哪些? 



     并不是延伸档名为。dll 者才是动态联结函数库(DLL ,Dynamic Link Library ),事实 



     上。exe 、。dll、。fon、。mod、。drv、。ocx 都是所谓的动态联结函数库。 



     Windows                C Runtimes  Windows API           C 

            程序调用的函数可分为              以及           两大部份。早期的 



     Runtimes 并不支持动态联结,但Visual C++ 4。0 之后已支持,并且在32 位操作系统 



      中已不再有small/medium/large 等内存模式之分。以下是它们的命名规则与使用时机: 



        LIBC。LIB  C Runtime  

      ■         这是         函数库的静态联结版本。 



        MSVCRT。LIB  C Runtime               MSVCRT40。DLL 

      ■            这是         函数库动态联结版本(                  )的 



            import  函数库。如果联结此一函数库,你的程序执行时必须有MSVCRT40。DLL 



        在场。 



     另一组函数,Windows API ,由操作系统本身(主要是Windows 三大模块GDI32。DLL 和 



     USER32。DLL 和KERNEL32。DLL )提供(注)。虽说动态联结是在执行时期才发生「联 



                                                                       5 


…………………………………………………………Page 68……………………………………………………………

      结」事实,但在联结时期,联结器仍需先为调用者(应用程序本身)准备一些适当的信 



      息,才能够在执行时期顺利「跳」到DLL 执行。如果该API 所属之函数库尚未加载, 



      系统也才因此知道要先行加载该函数库。这些适当的信息放在所谓的「import  函数库」 



      中。32 位Windows  的三大模块所对应的import  函数库分别为GDI32。LIB 和USER32。LIB 



      和KERNEL32。LIB 。 



      注:谁都知道,Windows 95 是16/32 位的混合体,所以旗下除了32 位的GDI32。DLL 、 



      USER32。DLL  KERNEL32。DLL    16   GDI。EXE  USER。EXE  

               和             , 又有   位的        、         和 

                                



      KRNL386。EXE 。32 位和16 位两组DLLs 之间以所谓的thunking layer 沟通。站在纯 



      粹APIs 使用者的立场,目前我们不必太搭理这个事实。 



      Windows 发展至今,逐渐加上的一些新的API 函数(例如mon Dialog、ToolHelp ) 



      并不放在GDI 和USER 和KERNEL 三大模块中,而是放在诸如MDLG。DLL 、 



      TOOLHELP。DLL 之中。如果要使用这些APIs ,联结时还得加上这些DLLs 所对应的 



      import  函数库,诸如DLG32。LIB 和TH32。LIB 。 



      很快地,在稍后的范例程序! §Generic! ¨  的makefile  中,你就可以清楚看到联结时期所需 



      的各式各样函数库(以及各种联结器选项)。 



需要什么头文件 ( ) 

                       。H 



      所有Windows 程序都必须包含WINDOWS。H 。早期这是一个巨大的头文件,大约有5000 



            Visual C++ 4。0                       WINDOWS。H  

      行左右,            已把它切割为各个较小的文件,但还以                    总括之。 



      除非你十分清楚什么API 动作需要什么头文件,否则为求便利,单单一个WINDOWS。H 



      也就是了。 



      不过,WINDOWS。H  只照顾三大模块所提供的API 函数,如果你用到其它system DLLs, 



      例如MDLG。DLL 或MAPI。DLL 或TAPI。DLL 等等,就得包含对应的头文件,例如 



      MDLG。H 或MAPI。H 或TAPI。H 等等。 



                                                                       6 


…………………………………………………………Page 69……………………………………………………………

以消息为基础,以事件驱动之 (                                         ,          ) 

                                            message based event driven 



       Windows 程序的进行系依靠外部发生的事件来驱动。换句话说,程序不断等待(利用一 



       个while  回路),等待任何可能的输入,然后做判断,然后再做适当的处理。上述的「输 



       入」是由操作系统捕捉到之后,以消息形式(一种数据结构)进入程序之中。操作系统 



       如何捕捉外围设备(如键盘和鼠标)所发生的事件呢?噢,USER 模块掌管各个外围的 



       驱动程序,它们各有侦测回路。 



       如果把应用程序获得的各种「输入」分类,可以分为由硬件装置所产生的消息(如鼠标 



                                      system queue         Windows  

       移动或键盘被按下),放在系统队列(                         )中,以及由            系统或其它 



       Windows 程序传送过来的消息,放在程序队列(application queue )中。以应用程序的眼 



       光来看,消息就是消息,来自哪里或放在哪里其实并没有太大区别,反正程序调用 



       GetMessage API 就取得一个消息,程序的生命靠它来推动。所有的GUI 系统,包括UNIX 



       的X Window  以及OS/2  的Presentation Manager ,都像这样,是以消息为基础的事件驱 



       动系统。 



       可想而知,每一个Windows 程序都应该有一个回路如下: 



              MSG msg; 



              while  (GetMessage (&msg; NULL; NULL; NULL)) { 



                             TranslateMessage (&msg); 



                             DispatchMessage (&msg); 



              } 



       // 以上出现的函数都是Windows API 函数 



       消息,也就是上面出现的MSG 结构,其实是Windows  内定的一种资料格式: 



       /* Queued message structure */ 



              typedef struct tagMSG 



               { 



                      HWND hwnd; 



                      UINT message; // WM_xxx    WM_MOUSEMOVE  WM_SIZE。。。 

                                            ,例如              , 



                      WPARAM wParam; 



                      LPARAM lParam; 



                      DWORD time; 



                      POINT pt; 



               } MSG; 



                                                                                   7 


…………………………………………………………Page 70……………………………………………………………

接受并处理消息的主角就是窗口。每一个窗口都应该有一个函数负责处理消息,程序员 



必须负责设计这个所谓的「窗口函数」(window procedure,或称为window function )。 



如果窗口获得一个消息,这个窗口函数必须判断消息的类别,决定处理的方式。 



            Windows  

以上就是                   程序设计最重要的观念。至于窗口的产生与显示,十分简单,有专 



      API                                        Windows  

门的         函数负责。稍后我们就会看到                                     程序如何把这消息的取得、分派、处 



理动作表现出来。 



                                                                                    MYAPP。EXE 



                                                                             WinMain(hInst; hPrev; 。。。) 

                                                                              { 

                                                                             MSG  msg; 

                                       Messages from                         RegisterClass(。。。); 

                                      other windows                          CreateWindow(。。。); 

       Mouse        Keyboard                                                 ShowWindow(。。。); 

       Driver        Driver            PostMessage()                         UpdateWindow(。。。); 

                                                                             while(GetMessage(&msg。。。)) { 

                                                                                 TranslateMessage(。。。); 

                                                                                 DispatchMessage(。。。); 

   System                                           Application              } 

   message                                          message                  return msg。wParam; 

   queue                                            queue                    } 



                                                                    
返回目录 上一页 下一页 回到顶部 9 10
快捷操作: 按键盘上方向键 ← 或 → 可快速上下翻页 按键盘上的 Enter 键可回到本书目录页 按键盘上方向键 ↑ 可回到本页顶部!
温馨提示: 温看小说的同时发表评论,说出自己的看法和其它小伙伴们分享也不错哦!发表书评还可以获得积分和经验奖励,认真写原创书评 被采纳为精评可以获得大量金币、积分和经验奖励哦!