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

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




箱、離合器、萬向傳動軸、引擎燃料系統、動力傳達裝置、懸吊裝置、煞車裝置　，是　

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　。。。　



否開起車來比較實實在在？了解構造原理之後，要來個甩尾大迴旋，比較知道該怎麼做　



吧，基本操作也比較不會出錯（很多煞車時順帶把離合器踏板給踩去，怕熄火。這　



習慣養成之後，高速公路就會要你的命）。　



依我之見，了解　　　　　　　　　　　　　原始碼是有必要的，尤其在導入部份　　這是影響個能否學　

　　　　　　　　　　　　　　　　MFC　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　…　



成　　MFC　　的關鍵。本好的　　MFC　　書籍應該讓程式員完全了解每個奇怪巨集（像是　



DECLARE_MESSAGE_MAP　　　　　　　、BEGIN_MESSAGE_MAP　　　　　　　、END_MESSAGE_MAP　　　　　　　　、　



　　　　　　　　　　　　　　　　　、　　　　　　　　　　　　　　　　　　　　　等等等）的背後所代表的機制，以及每個　

DECLARE_SERIAL　　　　　IMPLEMENT_SERIAL　　



必須改寫的虛擬函式（例如CWinApp：：InitInstance　、CDocument：：Serialize　、CView：：OnDraw　



等等等）背後所代表的意義與動作。但是當程式的主軸精神完全掌握之後，旁支應用（例　



如對話盒、控制元件、列印、預視）就不需要再那麼深入探究原始碼了。當然，這是指　



般性伲�的　　MFC　　書籍而言，MFC　　Internals　　本來就是要把　　MFC　　整個翻兩翻的，所以　



它照挖不铡�。　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　867　


…………………………………………………………Page　930……………………………………………………………

　　　　　　　　　　　　　　　　　　第五篇　　　　附錄　　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　nd　

　　　　　　　　　　　　　　　　　　　　　Dissecting　MFC　　　　2　　　Edition　



　　　　　　　　　　　　　　　　　　作者：侯俊傑　



　　　　　　　　　　　　　　　　　　出版公司：松崗　



　　　　　　　　　　　　　　　　　　出版日期：1996/10　



　　　　　　　　　　　　　　　　　　頁數：　　章，　　　　　　　　　　頁　

　　　　　　　　　　　　　　　　　　　　　　　　　13　　　　778　　



　　　　　　　　　　　　　　　　　　售價：NT　860。00　　。含光碟片。　



　　　　　　　　　　　　　　　　　　第篇　勿在浮砂築高臺　技術前提　

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　



　　　　　　　　　　　　　　　　　　　1。　　　　Win32　　程式基本觀念　



　　　　　　　　　　　　　　　　　　2。　　　　C＋＋　　的重要性伲�　



　　　　　　　　　　　　　　　　　　3。　　　　MFC　　六大關鍵技術之模擬　



　　　　　　　　　　　　　　　　　　第篇　　　　Visual　C＋＋　v4。0　　開發工具　



　　　　　　　　　　　　　　　　　　4。　　　　Visual　C＋＋　　整合性軟體開發環境　



　　　　　　　　　　　　　　　　　　第篇　湷觥　　　　　　　　　　　〕淌皆O計　

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　MFC　　



　　　　　　　　　　　　　　　　　　5。　　　　總觀　　Application　Framework　



　　　　　　　　　　　　　　　　　　6。　　　　MFC　　程式設計導論　　MFC　　程式的生與死　



　　　　　　　　　　　　　　　　　　7。　　　　個簡單而完整的　　MFC　　骨幹程式　



　　　　　　　　　　　　　　　　　　第篇　深入　　　　　　　　　　　　程式設計　

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　MFC　　



　　　　　　　　　　　　　　　　　　8。　　　　Document…View　　深入探討　



　　　　　　　　　　　　　　　　　　9。　　　　訊息映射與繞行　



　　　　　　　　　　　　　　　　　　　10。　　對話盒與　　DDX/DDV　



　　　　　　　　　　　　　　　　　　　11。　View　功能之加強與重繪效率之提昇　



　　　　　　　　　　　　　　　　　　　12。　　印表與預視　



　　　　　　　　　　　　　　　　　　　13。　　多重文件與多重顯示　



　　　　　　　　　　　　　　　　　　　14。　MFC　　多緒程式設計　



　　　　　　　　　　　　　　　　　　　15。　　定製個　　AppWizard　



　　　　　　　　　　　　　　　　　　　　　　站眾的肩膀　使用　　　　　　　　　　　　　　　　　　　　　　和　

　　　　　　　　　　　　　　　　　　　16。　　　　　　　　　　　　　　　　　　　　ponents　　　　ActiveX　Controls　



　　　　　　　　　　　　　　　　　　Appendix　A　　　　從搖籃到墳墓　　Windows　　的完全學習　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　無責任書評侯捷：　　　　　　　　　　　　　　大王　

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　/　　　　MFC　　



　　　　　　　　　　　　　　　　　　Appendix　B　　　　Scribble　Step5　　程式原始碼列表　



　　　　　　　　　　　　　　　　　　Appendix　C　　　　Visual　C＋＋　　所附範例程式樱А�



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　以　　　　　　　重建　　　　　　　　　　　　　　　　（　　　　　　　）　

　　　　　　　　　　　　　　　　　　Appendix　D　　　　　　MFC　　　　　　　Debug　Window　DBWIN　



　　　　　　　　　　　　　　　　　　我談這本書，可能會被譏以「分身替本尊說話」，但為了舉耍Ш脮�，以及秉持外舉不避　



　　　　　　　　　　　　　　　　　　仇、內舉不避親的原則，我不想閃躲。　



868　


…………………………………………………………Page　931……………………………………………………………

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　附錄Ａ　無責任書評　



這本書目前只有文版。已經有國內出版社積極表達爭取出版英文本的意願。大陸方面，　



則有多家出版社亟願將此書譯為簡體版，甚至直接　　email　　與作者聯絡。這本就是前陣子　



在　　　　　　　引起眾多討論的　深入湷錾钊霚出　MFC　，Dissecting　MFC　　。　

　　　　BBS　　　　　　　　　　　　　　　　　　深入湷錾钊霚出　　



依我看，本書橫亙在　Inside　　　　　　　　　Visual　　C＋＋　　和　MFC　Internals　兩書之間，有　InsideVisual　

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　



C＋＋　　的實用面，而在核心技術更擅勝場。有　MFC　Internals　　　　　　　　　　　　　　的深入面，而無其過於晦澀。　

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　



所謂核心技術，本書指的是：　



1。　　　應用程式和　　MFC　　framework　　的因果關係。這部份是你學習MFC　　程式設計的成敗　



　　　關鍵。因為太多不了第個台階。本書把耄Р氐摹�WinMain　　函式、視窗類別裕�冊、　

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　



　　　視窗誕生、訊息迴路等動作統統挖掘出來，讓屬於　　framework　　的那半邊曝光，和你　



　　　的應用程式碼這半邊拼兜出張完整的邏輯茫�絡圖。才不會堆積木老是少塊。　



　　　訊息映射（　　　　　　　　　　　　　　　　　　　）和命令繞行（　　　　　　　　　　　　　　　　　　　　　）。「物件導向」從來　

2。　　　　　　　　　　　Message　Mapping　　　　　　　　　　　　mand　Routing　



　　　洠в锌紤＇過　　　　　　　　　　　　　　訊息（那當然）。　　　　　　　　　　　　程式有大類別（　　　　　　　　　　　　　　　　　、　　　　　、　

　　　　　　　　　　　　　　　Windows　　　　　　　　　　　　　　　MFC　　　　　　　　　　　　　　　　　　application　frame　



　　　　　　　　　　　、　　），程式員最容易陷入的苦惱是不知道在哪個類別攔截並處理命　

　　　document　view　



　　　令訊息。那是因為洠в心軌蚩辞宄�訊息在類別的流動路線。流動路線的整個圖耄А�



　　　耄г谖∥∩綆p：在由　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　、　　　　　　　　　　　　　　　　　　　　　　　、　

　　　　　　　　　　　　　　　　　　　　　　　　　　DECLARE_MESSAGE_MAP　　　　　　BEGIN_MESSAGE_MAP　



　　　　　　　　　　　　　　　　　　　　　　　巨集以及其他各式各樣的　　　　　　　　　　　　　　　　　　　　　　　　　、　

　　　END_MESSAGE_MAP　　　　　　　　　　　　　　　　　　　　　　　　　　　　ON_MAND　　　　ON_WM_PAINT　



　　　等巨集架構起來的巨大網絡。當你的程式開始執行，整個　　MFC　　的絕大部份類　



　　　別，都已經貢獻出些資料，組成這張巨幅網絡（噢，是的，當然也耗用了你的記憶　



　　　體）。　



3。　　　Document/View/Template　　之間的關係。個程式如果支援兩份以的Documents　　，應　



　　　該如何管理？對應的使用者介面應該如何設定？Document　Template　　究竟是何用途？　



　　　這是這個主睿�要探討的睿�目。　



　　　　　　　　　　　　　　　　　　　　　　　　　（　　）和　　　　　　　　　　　　　　　　　　　　。把份　　　　　　　　　　　　寫入檔案　

4。　　　Runtime　Type　Information　RTTI　　　Dynamic　Creation　　　　　　document　　



　　　之，連同類別名稱和成員變數的值，洠в袉栴｝。是的，點問睿�也洠в校�但是讀出　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　869　


…………………………………………………………Page　932……………………………………………………………

　　　　　　　　　　　　　　　　　　第五篇　　　　附錄　　



　　　　　　　　　　　　　　　　　　　　　來就有問睿�了，因為你不可能讀個類別名稱到個字串然後對這個字串做　　new　



　　　　　　　　　　　　　　　　　　　　　動作。「從檔案讀出類別名稱然後產生其物件」，就是　　〃dynamic　creation〃　　的具體表　



　　　　　　　　　　　　　　　　　　　　　現。C＋＋　　不支援這項能力，但　　MFC　　非要不可，因為有太多時候需要　　dynamic　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　。其實你只要使用笨方法如，就可以解決　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　的問睿�：　

　　　　　　　　　　　　　　　　　　　　　creation　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　dynamic　creation　　



　　　　　　　　　　　　　　　　　　　　　　　　　//　pseudo　code　

　　　　　　　　　　　　　　　　　　　　　　　　　read　ClassName　to　str　

　　　　　　　　　　　　　　　　　　　　　　　　　if　（str　==　〃Class1〃）　

　　　　　　　　　　　　　　　　　　　　　　　　　　　　new　Class1；　

　　　　　　　　　　　　　　　　　　　　　　　　　else　if　（str　==　〃Class2〃）　

　　　　　　　　　　　　　　　　　　　　　　　　　　　　new　Class2；　

　　　　　　　　　　　　　　　　　　　　　　　　　else　if　（str　==　〃Class3〃）　

　　　　　　　　　　　　　　　　　　　　　　　　　　　　new　Class3；　

　　　　　　　　　　　　　　　　　　　　　　　　　else　if　（str　==　〃Class4〃）　

　　　　　　　　　　　　　　　　　　　　　　　　　　　　new　Class4；　

　　　　　　　　　　　　　　　　　　　　　　　　　！　K　



　　　　　　　　　　　　　　　　　　　　　MFC　　小組比我們聰明嗎？不會。但是他們比我們懂得包裝。他們在MFC　　framework　



　　　　　　　　　　　　　　　　　　　　　架構起個由所有類別相關資訊（包括類別名稱及建構函式）組成的類別型錄網絡　



　　　　　　　　　　　　　　　　　　　　　　（個串列），然後把類別名稱的比對動作埋藏在　　　　　　　　　　　　　　　　　　　　　　　　　　　　　虛擬函式。類別型錄　

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　Serialize　　



　　　　　　　　　　　　　　　　　　　　　網絡的每個成員就是　CRuntimeClass　　物件，網絡的組成則是藉由類別宣告時的　

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　



　　　　　　　　　　　　　　　　　　　　　DECLARE_DYNCREATE　　　　　　　和　　　　IMPLEMENT_DYNCREATE　　　　　　　　巨　集　完　成　。　



　　　　　　　　　　　　　　　　　　　　　RUNTIME_CLASS　　巨集就是取出「類別型錄網絡」的個元素（代表個類別）。　



　　　　　　　　　　　　　　　　　　　　　所以，當你的程式開始執行，整個　　MFC　　的絕大部份類別，都已經放在這個「類別　



　　　　　　　　　　　　　　　　　　　　　型錄網絡」之（噢，是的，當然也耗用了你的記憶體）。有了這網絡，RTTI　　（執行　



　　　　　　　　　　　　　　　　　　　　　時期型別辨識）和　　Dynamic　Creation　　都不是問睿�。　



　　　　　　　　　　　　　　　　　　5。　　　Persistence　。文件內容要用什麼型式寫到檔案去，才能夠再從檔案讀出來恢復為個　



　　　　　　　　　　　　　　　　　　　　　個的物件？這就是　　　　　　　　　　　　　　　　　　　（　　　　　稱之為　　　　　　　　　　　　　）要探討的睿�目。本書把　

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　persistence　MFC　　　　　　　　serialization　



　　　　　　　　　　　　　　　　　　　　　Serialize　　虛擬函式的內部行為全部挖掘出來，並且實際觀察個文件檔的　　hex　　傾印　



　　　　　　　　　　　　　　　　　　　　　內容。　



　　　　　　　　　　　　　　　　　　這五個部份是本書最精華的方，也是它獨步全球的方。要有這麼深入的了解，非得　



　　　　　　　　　　　　　　　　　　觀察　　MFC　　原始碼不可。本書把相關的　　MFC　　碼整理出來，加相當多的示意圖，MFC　



870　


…………………………………………………………Page　933……………………………………………………………

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　附錄Ａ　無責任書評　



Internals　　雖然挖得更廣，整理的功夫卻洠в羞@本好。　



這本書用詞相當精準。用詞精準在容易岐路的物件導向領域至為重要，許多細微的觀　



念就在字句推敲成形。　



實例方面，希望看到琳琅滿目的範例程式的讀者，將會大失所望。這本書使用Visual　C＋＋　



的標準範例　　Scribble　。只有13~16　章才有幾個作者自己設計的程式，而且教育價值雖有，　



實在有點其貌不揚。然而以Scribble　為範例主軸，有個意想不到的好處：常看　　Microsoft　



Systems　Journal　　或　　　Windows　Developer's　Journal　　的朋友就知道，許多作家喜歡在示範新　



技術或新構想時，以　　Scribble　　為載具。如果你對Scribble　　十分熟悉，閱讀那些文章可就　



瘢�輕就熟了。　



本書的許多精心插圖，是令驚喜的方。圖解千言萬語，在這裡獲得最佳裕�腳。　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　871　


…………………………………………………………Page　934……………………………………………………………

　　　　　　　　　　　　　　第五篇　　　　附錄　　



　　　　　　　　　　　　　　鍋湯，要放多少�｝才叫好？有喜歡重口味，有雅好清如水。　



　　　　　　　　　　　　　　本程式設計書籍，究竟要放多少碼，才能夠雅俗共賞，點頭？　



　　　　　　　　　　　　　　關於這點，有兩種完全迥異的看法。第種看法似乎頗佔風，他們說書籍應該是解　



　　　　　　　　　　　　　　釋程式的邏輯，程式的意念，程式設計的　呃　境界。因此出現在書的碼應該只能是　

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　。。。　。。。　



　　　　　　　　　　　　　　小小的、片段的、簡捷的。但凡有大落大落的碼出現，那便是不入流、難登大雅之　



　　　　　　　　　　　　　　堂。我看過好多書評對於那種有著許多程式碼的書明嘲暗諷，甚而大加撻伐（呵呵，外　



　　　　　　　　　　　　　　文期刊的書評很毒的）。　



　　　　　　　　　　　　　　如果程式碼用來充篇幅，那就罵得好。　



　　　　　　　　　　　　　　如果完整的碼用來給予完整的面觀，我就認為值得。　



　　　　　　　　　　　　　　其實，程式碼是贅餘還是適得其所，完全視讀者的個情況而定。　



　　　　　　　　　　　　　　Scribble　　範�