【文章內(nèi)容簡介】 要直接將控件拖進(jìn)對(duì)話框里，而不用寫任何代碼。 iMessaging 就 是典型的ＭＦＣ應(yīng)用程序，采用了ＭＦＣ對(duì)話框設(shè)計(jì)框架，但是為了設(shè)計(jì)一個(gè)友好美觀的操作界面，僅用微軟提供的控件類庫達(dá)不到預(yù)期的 基于局域網(wǎng)的聊天軟件的設(shè)計(jì)與實(shí)現(xiàn) 4 效果，因此，就必須重新繪制其對(duì)話框和控件的界面。而正由于微軟將這些控件封裝得很好，對(duì)于要修改它的屬性，派生一些美觀的子控件難度就顯得比較大。一般來說，實(shí)現(xiàn)對(duì)控件的重繪技術(shù)主要有子類化，自繪和重繪技術(shù)，由于ＭＦＣ框架太過于標(biāo)準(zhǔn)化，因此實(shí)現(xiàn)這些技術(shù)也是有一定的難度，這必須要對(duì)框架的結(jié)構(gòu)有一定的了解。 iMessaging 采用了的窗體背景重繪， listctrl 自繪，按鈕貼圖等方式實(shí)現(xiàn)了操作界面的 美觀。主要核心技術(shù)是ＧＤＩ雙緩沖繪圖。雙緩沖繪圖就是將待繪制的圖片保存到內(nèi)存里，當(dāng)需要繪制到屏幕上時(shí)，再一次性投遞到設(shè)備描述表里，這樣既避免了窗口重繪時(shí)的閃爍，又提高了繪制的速度和效率。BOOL CDC::CreatieCompatibleDC(CDC* pDC)函數(shù)用來創(chuàng)建一個(gè)兼容 DC,即在內(nèi)存里創(chuàng)建一個(gè) DC，以后的任何繪圖所需的操作，如選用何種畫筆，畫刷，字體等，都將在內(nèi)存中進(jìn)行，而不是在真實(shí)設(shè)備上下文里。隨后可以創(chuàng)建一張兼容位圖，需要繪制的圖像將，函數(shù)原型如下 BOOL CBitmap::CreateCiompatibleBitmap(CDC* pDC,int nWidth,int nHeight)。最后需要將兼容 DC里的東西投射到真實(shí)的 DC里， BOOL BitBlt(HDC hdcDest, int nXDest, int nYDest, int nWidth, int nHeight, HDC hdcSrc, int nXSrc, int nYSrc,DWORD dwRop )函數(shù)可以實(shí)現(xiàn)該功能，具體用法可參考 MSDN。 對(duì)話框的繪制比較容易， MFC 為對(duì)話框提供了 OnPaint 消息相應(yīng)函數(shù)，但是在該函數(shù)下繪制并不能從根本上重繪對(duì)話框，因?yàn)樵摵瘮?shù)還會(huì)調(diào)用CDialog::OnPaint 函數(shù)，在內(nèi)部還會(huì)再去重繪背景，因此要實(shí)現(xiàn)完全意義上的重繪背景，就必須響應(yīng) WM_ERASEBKGND 消息，在消息響應(yīng)函數(shù)里實(shí)現(xiàn)我們自己的繪制方法，然后直接返回 TRUE，不再調(diào)用 CDialog::OnEraseBkgnd()函數(shù)。為了實(shí)現(xiàn)像 那樣的界面，必須將對(duì)話框的屬性設(shè)置為 None 屬性，即沒有標(biāo)題欄，因此只有自己去實(shí)現(xiàn)標(biāo)題欄的功能。 CListCtrl重繪的方法有兩種 ,一種是采用微軟提供的 OWNERDRAW屬性 ,通過重載 DrawItem 虛函數(shù)來進(jìn)行重繪。另外一種就是 Customdraw 屬性，通過定義自繪消息響應(yīng)函數(shù)來進(jìn)行重繪。兩種方式有不同之處，前者需要對(duì)整個(gè) ListCtrl繪制，必須考慮到每一個(gè) item 項(xiàng)的繪制情況。而后者相對(duì)比較簡便，系統(tǒng)會(huì)在四個(gè)狀態(tài)的時(shí)候通知重繪，這四 個(gè)狀態(tài)分別是繪制前，繪制后，擦除前，擦除后，我們就可以按照自己的需要去繪制，并且我們只用考慮其中一項(xiàng) item 的繪制方 基于局域網(wǎng)的聊天軟件的設(shè)計(jì)與實(shí)現(xiàn) 5 法，就可以應(yīng)用于所有項(xiàng)。 iMessaging 采用了后者進(jìn)行對(duì)列表控件的重繪，實(shí)現(xiàn)了好友列表控件，群列表控件類。 對(duì)于 VC6 開發(fā)環(huán)境，微軟提供的通用 button 控件的外觀從現(xiàn)在看來的確不太美觀，無法實(shí)現(xiàn)動(dòng)態(tài)狀態(tài)的效果。那么因此就必須重新創(chuàng)建一個(gè)派生于CButton 的按鈕類，由于該類將應(yīng)用于本軟件的所有按鈕控件，因此做成可貼狀態(tài)圖的按鈕控件最為合適。狀態(tài)分為移出按鈕，懸浮按鈕，按下按鈕，禁用按鈕四 種狀態(tài)，我們只需要提供相應(yīng)的狀態(tài)的 Bitmap 就可以。具體重繪方法就是采用前面提到的 OWNERDRAW屬性，重載虛函數(shù) DrawItem。而捕獲鼠標(biāo)的移入移出消息可以使用 _TrackMouseEvent 函數(shù)，通過設(shè)置 TRACEMOUSEEVENT 結(jié)構(gòu)體的值來捕捉該消息。其移出消息對(duì)應(yīng)的是 WM_MOUSELEAVE，移入按鈕消息是WM_MOUSEHOVER，分別定義其消息相應(yīng)函數(shù)，這樣就能實(shí)現(xiàn)狀態(tài)的更替，再進(jìn)行相應(yīng)的繪制。 Winsock 編程 Windows 下網(wǎng)絡(luò)編程的規(guī)范－ Windows Sockets 是 Windows 下得到廣泛應(yīng)用的、開放的、支持多種協(xié)議的網(wǎng)絡(luò)編程接口。 它實(shí)現(xiàn)了標(biāo)準(zhǔn) socket 編成的函數(shù)，提供了一套屬于 windows 下的套接子 API。其 通信的基礎(chǔ)是套接 字 （ Socket），一個(gè)套接 字 是通訊的一端。在這一端上你可以找到與其對(duì)應(yīng)的一個(gè)名字。一個(gè)正在被使用的套接字都有它的類型和與其相關(guān)的進(jìn)程。套接字存在于通訊域中。通訊域是為了處理一般的線程通過套接字通訊而引進(jìn)的一種抽象概念。套接字通常和同一個(gè)域中的套接字交換數(shù)據(jù)（數(shù)據(jù)交換也可能穿越域的界限，但這時(shí)一定要執(zhí)行某種解釋程序）。 Windows Sockets 規(guī)范支持單一的通訊域，即 Inter域。各種進(jìn)程使用這個(gè)域互相之間用 Inter協(xié)議族來進(jìn)行通訊（ Windows Sockets 以上的版本支持其他的域，例如Windows Sockets 2）。套接字可以根據(jù)通訊性質(zhì)分類；這種性質(zhì)對(duì)于用戶是可見的。應(yīng)用程序一般僅在同一類的套接字間通訊。不過只要底層的通訊協(xié)議允許，不同類型的套接字間也照樣可以通訊。用戶目前可以使用兩種套接字，即流套接字和數(shù)據(jù)報(bào)套接字。流套接字提供了雙向的，有序的，無重復(fù)并且無記錄邊界的數(shù)據(jù)流服務(wù)。數(shù)據(jù)報(bào)套接字支持 雙向的數(shù)據(jù)流， 基于局域網(wǎng)的聊天軟件的設(shè)計(jì)與實(shí)現(xiàn) 6 但并不保證是可靠，有序，無重復(fù)的。也就是說，一個(gè)從數(shù)據(jù)報(bào)套接字接收信息的進(jìn)程有可能發(fā)現(xiàn)信息重復(fù)了，或者和發(fā)出時(shí)的順序不同。數(shù)據(jù)報(bào)套接字的一個(gè)重要特點(diǎn)是它保留了記錄邊界。對(duì)于這一特點(diǎn)，數(shù)據(jù)報(bào)套接字采用了與現(xiàn)在許多包交換網(wǎng)絡(luò)（例如以太網(wǎng)）非常類似的模型 。其中 TCP協(xié)議就是基于流套接字，而 UDP 協(xié)議基于數(shù)據(jù)報(bào)套接字， iMessaing 聊天程序主要基于 UDP 協(xié)議，而在特殊操作下又采用 TCP 協(xié)議保證其數(shù)據(jù)的可靠性。 在設(shè)計(jì)階段，需分析該軟件適用于什么樣的地協(xié)議進(jìn)行通訊，還必須分析該系統(tǒng)應(yīng)該適合于何種套接 字 IO 操作。目前， windows 提供了多種套接字 IO模型，如阻塞式 IO，非阻塞式 IO，事件 IO，重疊 IO（可提醒 IO），完成端口等，每一種 IO 模型都具有自身的優(yōu)勢(shì)和缺陷，其中完成端口可以達(dá)到目前 windows 平臺(tái)下最高 IO 性能。 由于是基于 UDP 協(xié)議，并且考慮到在同一時(shí)間處理得命令并不會(huì)很大的情況，服務(wù)器和客戶端均采用基于非阻態(tài)的 IO模型實(shí)現(xiàn)命令的傳輸。 windows 提供了一個(gè) CAysncSocke 異步 套接字類，它是基于 非阻塞 模型，對(duì) Socket 函數(shù)進(jìn)行了良好的 封裝 ， CAsyncSocket::Create()有一個(gè)參數(shù)指明了你想要處理哪些Socket 事件，你關(guān)心的事件被指定以后，這個(gè) Socket 默認(rèn)就被用作了異步方式。CAsyncSocket 的 Create()函數(shù)，除了創(chuàng)建了一個(gè) SOCKET 以外，還創(chuàng)建了個(gè)CSocketWnd 窗口對(duì)象，并使用 WSAAsyncSelect()將這個(gè) SOCKET 與該窗口對(duì)象關(guān)聯(lián)，以讓該窗口對(duì)象處理來自 Socket 的事件 (消息 )，然而 CSocketWnd 收到Socket 事件之后，只是簡單地回調(diào) CAsyncSocket::OnReceive()等虛函數(shù)。所以CAsyncSocket 的派生類，只需要在這些虛函數(shù)里添加發(fā)送和接收的代碼。 因此介于微軟提供的強(qiáng)大類方法，就很容易實(shí)現(xiàn)數(shù)據(jù)的通信。 基于 UDP 的文件傳輸 要實(shí)現(xiàn)文件傳輸?shù)姆绞接泻芏喾N，常用的方式就是像 MSN 那樣基于 TCP 的文件傳輸，這樣的傳輸很穩(wěn)定，可靠，容易實(shí)現(xiàn)，但傳輸?shù)乃俣群托蕰?huì)比較慢。為了提高傳輸速度，我們可以采用 UDP 協(xié)議來傳輸文件，由于 UDP 協(xié)議傳輸?shù)臄?shù)據(jù)不具有可靠性，在網(wǎng)絡(luò)環(huán)境差的地方很容易出現(xiàn)丟包，亂序等現(xiàn)象，直接采用 基于局域網(wǎng)的聊天軟件的設(shè)計(jì)與實(shí)現(xiàn) 7 UDP 來傳輸文件是不行的，那么就必須采用某種算法對(duì)其傳輸?shù)目煽啃赃M(jìn)行保證。我們可以模仿 TCP 的通訊機(jī)制來實(shí)現(xiàn)可靠的 UDP 傳輸。實(shí)際上， TCP的三次握手的確讓通訊數(shù)據(jù)得到了有序，有效地保證，但是正是因?yàn)檫@樣繁瑣的數(shù)據(jù)驗(yàn)證，導(dǎo)致它傳輸大量數(shù)據(jù)效率低下，在 TCP 實(shí)現(xiàn)內(nèi)部，實(shí)際上是采用了窗口大小為 1 的滑動(dòng)窗口算法進(jìn)行數(shù)據(jù)驗(yàn)證，因此， UDP 可以借于此思想，采用滑動(dòng)窗口算法和 CRC 冗余效驗(yàn)來保證數(shù)據(jù)的有效性，同時(shí)也會(huì)提高傳輸?shù)乃俣?。由于基于UDP 的文件傳輸在網(wǎng)絡(luò)環(huán)境差的情況下可能會(huì)大量丟包，因此不斷重復(fù)發(fā)包會(huì)導(dǎo)致網(wǎng)絡(luò)擁塞（ TCP 在內(nèi)部實(shí)現(xiàn)了流量控制，因此發(fā)生網(wǎng)絡(luò)擁塞可能性很?。?，這是其最大的缺陷。為了保證 速度，就會(huì)造成網(wǎng)絡(luò)擁塞，為了網(wǎng)絡(luò)的暢通，就不能保證速度，兩種傳輸方式的各據(jù)優(yōu)劣勢(shì)。 多線程編程 多線程編成是網(wǎng)絡(luò)編成的基礎(chǔ)，幾乎所有的網(wǎng)絡(luò)編程都將涉及到多個(gè)線程的數(shù)據(jù)傳輸，并且還要實(shí)現(xiàn)界面和數(shù)據(jù)處理互不影響。多線程編成雖說是基礎(chǔ)，但是卻是一個(gè)難點(diǎn)，因?yàn)榫€程同步的確比我們想象的復(fù)雜得多。要理解多線程編成就必須從以下幾個(gè)方面理解：一、操作系統(tǒng)多任務(wù)概念；二、線程和進(jìn)程的聯(lián)系與區(qū)別；三、如何創(chuàng)建并管理銷毀一個(gè)線程；四、何謂線程同步，怎樣同步。 什么是多任務(wù)概念？用通俗易懂的話就是幾個(gè)運(yùn)行的任務(wù)“同時(shí)”進(jìn) 行，比如 Windows 就是典型的多任務(wù)操作系統(tǒng)，我們可以同時(shí)進(jìn)行聽歌，打游戲，聊，在基于這種理念的系統(tǒng)感覺就像所有的程序在同時(shí)運(yùn)行一樣。但實(shí)際上在單CPU 的機(jī)子上，這些程序并不是同時(shí)在運(yùn)行（即便是在多 CPU 的電腦上，也不可能所有程序同時(shí)運(yùn)行），所有的程序都以某種調(diào)度算法，按照優(yōu)先級(jí)，依次獲取CPU 時(shí)間，每當(dāng)一個(gè)程序獲得 CPU 時(shí)間后，它就會(huì)得到運(yùn)行，而當(dāng)運(yùn)行一段時(shí)間后，操作系統(tǒng)會(huì)將其暫停，再接換新的線程來運(yùn)行。由于電腦的速度很快，這種非并發(fā)的模式卻可以達(dá)到類似并發(fā)的效果。實(shí)際上，正如前面所說，操作系統(tǒng)并非 是給某一程序分配時(shí)間片，準(zhǔn)確的說是給這個(gè)程序里的某一線程分配了時(shí)間片。因此，在多任務(wù)操作系統(tǒng)中（若有線程的話），線程將是運(yùn)行的最小單位。 在 windows 系統(tǒng)中，進(jìn)程和線程是最為重要的兩個(gè)概念，因?yàn)檎麄€(gè)系統(tǒng)就是基于進(jìn)程和線程的。那么進(jìn)程和線程有什么區(qū)別和聯(lián)系呢？進(jìn)程實(shí)際就是一個(gè)運(yùn) 基于局域網(wǎng)的聊天軟件的設(shè)計(jì)與實(shí)現(xiàn) 8 行的程序，該程序有自己的堆?？臻g，有自己的線程（至少有一個(gè)主線程），并且可以創(chuàng)建其它進(jìn)程或線程。有一個(gè)概念容易搞錯(cuò)，就是進(jìn)程是否能獲得 CPU時(shí)間片？實(shí)際上，進(jìn)程是無法獲取 CPU 時(shí)間片，只有該進(jìn)程里的線程才能，所以說，真正執(zhí)行代碼的是 線程，而進(jìn)程只能管理線程，管理內(nèi)存等。 在 iMessaging 程序里，涉及了諸多對(duì)線程的創(chuàng)建，管理和銷毀工作，特別是在服務(wù)器部分，為了保證數(shù)據(jù)響應(yīng)的即時(shí)性，必須對(duì)每一個(gè)處理創(chuàng)建一個(gè)線程。常用的創(chuàng)建線程函數(shù)為 CreateThread 和 _beginthreadex,兩函數(shù)功能幾乎一樣（在某些特殊地方，兩者用法需注意，推薦用后者），在創(chuàng)建前必須定義一個(gè)按照線程函數(shù)原型的函數(shù)，將其地址傳給創(chuàng)建線程函數(shù)，讓操作系統(tǒng)知道即將從哪個(gè)地方運(yùn)行線程。除此之外，還可以傳遞參數(shù)，供線程使用。若創(chuàng)建成功，該函數(shù)會(huì)返回一個(gè) HANDLE，這個(gè)句柄標(biāo)示了剛創(chuàng)建的線程內(nèi)核對(duì)象，當(dāng)線程創(chuàng)建成功后，必須調(diào)用 CloseHandle 函數(shù)將其關(guān)閉，這是因?yàn)槿绻魂P(guān)閉該內(nèi)核句柄，當(dāng)線程退出后，操作系統(tǒng)并沒有銷毀該線程，造成資源浪費(fèi)，這是因?yàn)楂@取一個(gè)實(shí)內(nèi)核句柄都會(huì)增加內(nèi)核使用計(jì)數(shù)，只有當(dāng)該內(nèi)核對(duì)象的使用計(jì)數(shù)為 0時(shí)，才會(huì)銷毀該內(nèi)核對(duì)象，線程也是如此。常用的銷毀線程函數(shù)是 ExitThread，TermelateThread 函數(shù)，但推薦使用函數(shù)返回的方式結(jié)束進(jìn)程，因?yàn)椴僮飨到y(tǒng)會(huì)自動(dòng)調(diào)用 ExitThread 函數(shù)，并回收分配的內(nèi)存資源。 由于多個(gè)線程在同時(shí)運(yùn)行的時(shí) 候，會(huì)對(duì)共享數(shù)據(jù)進(jìn)行訪問或修改，那么就必須要注意數(shù)據(jù)同步， windows 給我們提供了多種數(shù)據(jù)同步的方法，比如基于用戶模式的原子鎖，臨界區(qū)， Slim 讀寫鎖等，還有基于內(nèi)核模式的內(nèi)核對(duì)象，如互斥對(duì)象，事件對(duì)象，信號(hào)量，條件變量等。在 iMessaging 聊天程序中，最常用的是臨界區(qū)，原因是基于用戶模式，同步效率快，服務(wù)器可以進(jìn)行更多的操作，其次還用到了事件對(duì)象，由于臨界區(qū)太過單一的功能，并不能滿足有些數(shù)據(jù)同步的需要，因此用到了功能強(qiáng)大的事件對(duì)象，在 MFC中，事件對(duì)象被封裝成了 CEvent類，在 SDK 下，可以用調(diào)用 CreateEvent API 函數(shù)創(chuàng)建一個(gè)事件對(duì)象。 擴(kuò)展功能 —— 廣域網(wǎng)聊天 由于該課題是基于局域網(wǎng)的聊天軟件，那如何實(shí)現(xiàn)廣域網(wǎng)的聊天呢？實(shí)際上，在廣域網(wǎng)中實(shí)現(xiàn)基于 UDP 的聊天功能幾乎不可能，那是因?yàn)榇蠖鄶?shù)的電腦用 基于局域網(wǎng)的聊天軟件的設(shè)計(jì)與實(shí)現(xiàn) 9 戶在其小型網(wǎng)內(nèi)都會(huì)有一道 NAT 屏障擋住，由于 UDP 是不可靠的， NAT 發(fā)現(xiàn)當(dāng)前IP 和端口是不可信任的，那么就會(huì)將該數(shù)據(jù)包擋在墻外，這樣就無法實(shí)現(xiàn)聊天功能。那么為了解決這個(gè)問題，就必須了解何謂信任的 IP 和端口。一般來講，只要發(fā)現(xiàn)該主機(jī)曾經(jīng)主動(dòng)向該 IP 發(fā)送過信息，那么 NAT 會(huì)紀(jì)錄下來，并添加到任信列表里面去。