簡介面向使用 Visual Studio 2010 進(jìn)行 Windows 桌面開發(fā)的初學(xué)者和中級程序員講解 EDIT 控件在 MFC/對話框程序中的實(shí)際應(yīng)用。內(nèi)容覆蓋控件的創(chuàng)建與屬性調(diào)整、EN_CHANGE 等事件處理、文本獲取與設(shè)置、數(shù)字和字符長度限制、多行編輯、只讀與回車換行格式控制、光標(biāo)與滾動條操作、輸入錯誤提示并涉及打印預(yù)覽和自定義繪制等 GDI 高級用法可滿足從基礎(chǔ)表單到復(fù)雜交互界面的開發(fā)需求。資源包為 rar 壓縮格式共 52 個文件大小約 40.82MB主要包含 Visual Studio 2010 工程類文件如 cpp/h 源碼、rc 資源腳本、vcxproj 工程配置、sln 解決方案、exe 可執(zhí)行程序以及調(diào)試過程中生成的 pdb/obj 等文件便于讀者直接打開工程查看源碼并運(yùn)行體驗。已有 610 人學(xué)習(xí)下載適合正在學(xué)習(xí) MFC 控件編程或希望系統(tǒng)掌握 EDIT 控件 API 的開發(fā)者參考。1. EDIT控件桌面開發(fā)里那個被低估的輸入基石很多開發(fā)者第一次接觸 EDIT控件是在 Windows 桌面編程的入門階段——某個窗口上需要輸入文字于是拖了一個編輯框進(jìn)去跑起來能打字就算完事。但等到做真實(shí)業(yè)務(wù)的時候你會發(fā)現(xiàn)這玩意兒的坑比想象中深限制輸入格式、處理內(nèi)容變化通知、多行文本的滾動、密碼框的掩碼行為、輸入法狀態(tài)切換每一個都能讓產(chǎn)品體驗崩掉一半。EDIT控件本質(zhì)上是 Win32 里最基礎(chǔ)的文本輸入組件在 MFC 里對應(yīng) CEdit在 WinForms/WPF 里有同族控件但核心機(jī)制和消息體系一脈相承。這篇文章只解決三類問題EDIT控件能干什么、在代碼里怎么落地、以及那些文檔不會告訴你的邊界條件。適合正在做 Windows 桌面工具、工控上位機(jī)界面、或者剛接手老項目要改輸入模塊的開發(fā)者。2. EDIT控件的底層邏輯從窗口類到消息循環(huán)2.1 三種創(chuàng)建方式與初始化時機(jī)創(chuàng)建 EDIT控件最直接的方式是在父窗口的 WM_CREATE 里調(diào)用 CreateWindow窗口類名寫作 EDIT這是系統(tǒng)預(yù)注冊的類不需要額外注冊。另一種是直接在對話框模板里聲明讓對話框管理器在初始化時自動創(chuàng)建。第三種是通過 MFC 的 CEdit 類先聲明成員變量再在對話框的 OnInitDialog 里調(diào)用 SubclassDlgItem 綁定。三種方式各有適用場景手寫 CreateWindow 適合動態(tài)生成和定制樣式對話框模板適合固定布局CEdit 適合需要頻繁調(diào)用封裝方法的業(yè)務(wù)代碼。// 方式一在父窗口的 WM_CREATE 里動態(tài)創(chuàng)建 HWND hEdit CreateWindow( LEDIT, // 窗口類名系統(tǒng)內(nèi)置 L, // 初始文本 WS_CHILD | WS_VISIBLE | WS_TABSTOP | ES_LEFT | ES_AUTOHSCROLL, // 樣式組合ES_ 系列是編輯框?qū)Ｓ?10, 10, 200, 24, // 位置和尺寸 hWndParent, // 父窗口句柄 (HMENU)IDC_EDIT_NAME, // 控件ID后續(xù)消息識別要用 GetModuleHandle(NULL), NULL );這段代碼里 ES_LEFT 指定文本水平左對齊ES_AUTOHSCROLL 讓單行編輯框在內(nèi)容超出寬度時自動橫向滾動。WS_TABSTOP 保證鍵盤 Tab 可以聚焦到它這對表單應(yīng)用是剛需。控件 ID 用整數(shù)宏定義后續(xù)所有基于控件的操作——比如讀取內(nèi)容、設(shè)置焦點(diǎn)、處理通知——都要靠這個 ID 來定位。MFC 場景下更推薦在 OnInitDialog 里綁定因為此時對話框模板已經(jīng)完成布局編輯框已經(jīng)存在只需要把句柄交給封裝類// 方式二MFC 對話框類中的綁定 BOOL CMyDialog::OnInitDialog() { CDialogEx::OnInitDialog(); // 將模板里的 IDC_EDIT_IP 控件與成員變量關(guān)聯(lián) m_editIP.SubclassDlgItem(IDC_EDIT_IP, this); // 限定輸入字符范圍只允許 IP 地址字符 m_editIP.SetLimitText(15); return TRUE; }SubclassDlgItem 的底層就是拿控件句柄去做窗口過程替換把 CEdit 的消息處理接入 MFC 的消息路由。注意 SetLimitText 的參數(shù)是 15這是 IPv4 地址的最大長度如果不設(shè)默認(rèn)單行 EDIT 控件允許大約 32K 字符但行為上可能會限制輸入框的實(shí)際可見容量。初始化時機(jī)上動態(tài)創(chuàng)建的控件必須在父窗口顯示之前設(shè)置好初始文本否則會出現(xiàn)用戶看到控件時內(nèi)容才寫入的閃爍。2.2 控件 ID 的策略與父子窗口通信EDIT控件作為子窗口和父窗口的通信主要靠 WM_COMMAND。當(dāng)用戶對編輯框執(zhí)行某些操作——修改文本、失去焦點(diǎn)、按回車——編輯框會向父窗口發(fā)送通知碼。識別這個通知碼需要兩個信息控件 ID 和通知類型?？丶?ID 的規(guī)劃建議從 1000 開始遞增避免和菜單 ID 撞車。對話框模板資源里同一資源文件下的菜單 ID 通常都小于 100兩者并不存在硬性沖突但養(yǎng)成分區(qū)習(xí)慣能少出很多玄學(xué)問題。// 父窗口窗口過程里接收編輯框通知 case WM_COMMAND: { WORD wNotifyCode HIWORD(wParam); WORD wID LOWORD(wParam); HWND hCtrl (HWND)lParam; if (wID IDC_EDIT_NAME wNotifyCode EN_CHANGE) { // 文本發(fā)生變化立即讀取 wchar_t buf[64]; GetWindowText(hCtrl, buf, 64); UpdateButtonState(buf); // 比如有內(nèi)容才啟用確定按鈕 } break; }這段代碼的關(guān)鍵是 EN_CHANGE 和 EN_UPDATE 的區(qū)別。EN_UPDATE 是在控件將要重繪時發(fā)送此時文本還未最終確定EN_CHANGE 是在文本已經(jīng)修改之后發(fā)送這時讀到的內(nèi)容一定是用戶最終輸入的結(jié)果。實(shí)際業(yè)務(wù)里監(jiān)聽 EN_CHANGE 就夠因為取到的一定是新文本。另一個容易踩坑的地方是 lParam很多開發(fā)者忽略它在控件通知里的傳遞其實(shí)它就是那個編輯框的 HWND。有了 hCtrl 就不需要通過 GetDlgItem 再查一次句柄直接用來讀數(shù)據(jù)效率更高。3. 讀寫編輯框內(nèi)容的三種路徑與消息細(xì)節(jié)3.1 GetWindowText / SetWindowText 的局限和補(bǔ)救最常用的讀法是 GetWindowText直接傳句柄和緩沖區(qū)。但這個 API 有個隱藏限制跨進(jìn)程讀取時它只返回窗口標(biāo)題欄的文本而不是 EDIT 控件里的內(nèi)容。同進(jìn)程內(nèi)使用沒問題但如果你開發(fā)的是需要讀取外部進(jìn)程窗口里編輯框內(nèi)容的小工具——比如自動化測試腳本讀取目標(biāo)程序輸入框的值——GetWindowText 就是陷阱。必須改用 SendMessage 發(fā) WM_GETTEXT 消息消息機(jī)制繞過了標(biāo)題欄的限定直接讓控件自己把內(nèi)容拷貝出來。// 跨進(jìn)程讀取編輯框內(nèi)容的安全做法 HWND hTargetEdit FindWindowEx(hWndParent, NULL, LEDIT, NULL); wchar_t buffer[256]; SendMessage(hTargetEdit, WM_GETTEXT, 256, (LPARAM)buffer);參數(shù)說明WM_GETTEXT 的 wParam 是緩沖區(qū)能容納的字符數(shù)lParam 是緩沖區(qū)指針?？丶盏较⒑髸盐谋緩?fù)制到緩沖并返回實(shí)際復(fù)制的字符數(shù)。注意緩沖區(qū)聲明用的是 wchar_t因為 EDIT 控件內(nèi)部是 Unicode 存儲如果用 char 數(shù)組中文內(nèi)容會直接變成亂碼。這條同樣適用于同進(jìn)程內(nèi)——直接用 SendMessage 替代 GetWindowText 不算錯只是沒必要同進(jìn)程時 Windows 沒有區(qū)分二者的內(nèi)部路徑。寫入側(cè)同理SetWindowText 同進(jìn)程可用跨進(jìn)程就必須發(fā) WM_SETTEXT。而且 SetWindowText 有個附加問題它會觸發(fā) EN_UPDATE 和 EN_CHANGE 通知如果你的 EN_CHANGE 處理邏輯里又去調(diào)用 SetWindowText就會形成遞歸調(diào)用。常見做法是加一個布爾標(biāo)志位 m_bUpdating寫入時置真通知處理時看到標(biāo)志為真就跳過。// 防止 EN_CHANGE 遞歸寫入 void CMyDialog::SetEditText(const CString text) { m_bUpdating TRUE; m_editName.SetWindowText(text); m_bUpdating FALSE; } void CMyDialog::OnEnChangeEditName() { if (m_bUpdating) return; // 正常業(yè)務(wù)處理 }3.2 按字符讀取WM_GETTEXTLENGTH 與 EM_GETLINE 的場景表單場景里讀整個編輯框內(nèi)容就夠了但行編輯框有時候需要逐行處理。比如一個多行 EDIT 控件用于記錄日志你要從中提取最后一行的時間戳。用 GetWindowText 全量讀取再拆行不是不行但多行文本可能到達(dá)幾十 KB緩沖區(qū)分配就是麻煩事。此時先發(fā) WM_GETTEXTLENGTH 拿字節(jié)數(shù)再按需分配或者直接逐行拉取更穩(wěn)。// 獲取編輯框總字符數(shù) int len (int)SendMessage(hEdit, WM_GETTEXTLENGTH, 0, 0); // 獲取指定行文本 int lineIndex 3; // 行號從 0 開始0 是第一行 wchar_t lineBuffer[128]; int lineLen (int)SendMessage(hEdit, EM_GETLINE, lineIndex, (LPARAM)lineBuffer); lineBuffer[lineLen] L\0;EM_GETLINE 的返回值是拷貝到緩沖區(qū)的字符數(shù)行緩沖數(shù)組應(yīng)預(yù)分配足夠大否則超長行會被靜默截斷。這里有個細(xì)節(jié)EM_GETLINE 不會檢查緩沖區(qū)上限行內(nèi)容超出時不會給你報錯只會把緩沖區(qū)填滿然后返回實(shí)際字符數(shù)。所以用這個宏之前一般先發(fā) EM_LINELENGTH 查詢該行長度再決定緩沖區(qū)大小。多行編輯框的底層是逐行維護(hù)文本索引不需要把所有行拼成一個連續(xù)字符串這是它在處理超大日志時的性能優(yōu)勢。3.3 剪貼板交互與選擇范圍控制編輯框天然支持 CtrlC/V/X但代碼里需要主動操控剪貼板時只靠 WM_COPY、WM_PASTE 是不夠的因為編輯框自己處理這些消息的前提是內(nèi)部有選中區(qū)域。很多時候業(yè)務(wù)邏輯是在按鈕點(diǎn)擊里把整個編輯框的內(nèi)容復(fù)制走或者把程序生成的文本寫入編輯框并全選。全選操作發(fā) EM_SETSEL參數(shù)傳 0 和 -1 表示從開頭到結(jié)尾。// 全選并復(fù)制 SendMessage(hEdit, EM_SETSEL, 0, -1); SendMessage(hEdit, WM_COPY, 0, 0); // 設(shè)置光標(biāo)到末尾 int pos (int)SendMessage(hEdit, EM_GETTEXTLENGTH, 0, 0); SendMessage(hEdit, EM_SETSEL, pos, pos);參數(shù)細(xì)節(jié)EM_SETSEL 的 wParam 是起始位置lParam 是結(jié)束位置-1 表示到最后。設(shè)置完選區(qū)后 WM_COPY 會觸發(fā)剪貼板寫入。注意 EM_SETSEL 傳兩個相同位置時是取消選區(qū)并把光標(biāo)移到那個點(diǎn)。很多新手在這個API上傳 0 和 -1 時以為是可以執(zhí)行了其實(shí)這個選區(qū)操作之后還要自己做復(fù)制或刪除動作。剪貼板復(fù)制是異步的Copy 調(diào)用返回時內(nèi)容還在內(nèi)部系統(tǒng)會接著觸發(fā) WM_RENDERALLFORMATS 之類消息所以復(fù)制完立刻讀剪貼板偶爾會拿不到數(shù)據(jù)正確做法是先讓編輯框處理完這一切再在稍后的消息循環(huán)里讀。4. 樣式組合與輸入行為控制4.1 單行、多行、密碼框的樣式矩陣EDIT控件的輸入形態(tài)完全由 ES_ 樣式組合決定同一套消息機(jī)制下不同樣式組合呈現(xiàn)出完全不同的交互。單行編輯框使用默認(rèn)無 ES_MULTILINE 的狀態(tài)配合 ES_AUTOHSCROLL 橫向滾動。多行框加 ES_MULTILINE如果再加 ES_AUTOVSCROLL 和 ES_WANTRETURN回車就會在框內(nèi)換行而不是觸發(fā)默認(rèn)按鈕。密碼框加 ES_PASSWORD鍵入字符顯示為掩碼字符默認(rèn)是星號。// 創(chuàng)建多行自動換行的日志區(qū)域 HWND hLogBox CreateWindow( LEDIT, L, WS_CHILD | WS_VISIBLE | WS_VSCROLL | ES_MULTILINE | ES_AUTOVSCROLL | ES_READONLY, // 日志區(qū)通常不允許用戶編輯 10, 40, 480, 200, hWndParent, (HMENU)IDC_EDIT_LOG, GetModuleHandle(NULL), NULL );樣式細(xì)節(jié)ES_READONLY 和 WS_DISABLED 都能讓用戶無法輸入但前者控件仍能接收焦點(diǎn)、可選中復(fù)制文本后者整個控件灰掉連焦點(diǎn)都拿不到。日志場景用 ES_READONLY 就是為了讓用戶能選擇日志文本去復(fù)制。ES_WANTRETURN 在多行框里很重要如果沒加用戶在框內(nèi)按回車會觸發(fā)父窗口的 IDOK 按鈕——對話框一關(guān)日志都沒了。ES_AUTOVSCROLL 讓內(nèi)容超高時自動上翻配合 ES_MULTILINE 才是完整的滾動日志表現(xiàn)。4.2 文本限制與輸入過濾限制編輯框可輸入字符類型有兩條路線。路線一樣式級限制最典型的是 ES_NUMBER 樣式只允許數(shù)字 0-9它內(nèi)部屏蔽非數(shù)字字符的消息。路線二在 EN_CHANGE 通知里做合法性校驗不合法就撤銷或替換。路線二更靈活能實(shí)現(xiàn) IP 地址限四位、十六進(jìn)制限 A-F 和數(shù)字、金額限小數(shù)位等業(yè)務(wù)規(guī)則。// 在 EN_CHANGE 里過濾掉非十六進(jìn)制字符 void CMyDialog::OnEnChangeEditHex() { if (m_bUpdating) return; CString str; m_editHex.GetWindowText(str); CString filtered; for (int i 0; i str.GetLength(); i) { wchar_t ch str[i]; if ((ch L0 ch L9) || (ch LA ch LF) || (ch La ch Lf)) { filtered ch; } } if (filtered ! str) { m_bUpdating TRUE; m_editHex.SetWindowText(filtered); m_editHex.SetSel(filtered.GetLength(), filtered.GetLength()); m_bUpdating FALSE; } }這段代碼的思路是用戶每次改動都會觸發(fā) EN_CHANGE讀到完整文本后掃描一遍非法字符全部剔除再把過濾后的文本寫回。SetSel 把光標(biāo)移到末尾否則每次寫入都會導(dǎo)致光標(biāo)跳到開頭。這個方案能在用戶輸入非法字符的瞬間把他擋回去體驗上比彈窗提示好得多。需注意SetWindowText 會再次觸發(fā) EN_CHANGE所以 m_bUpdating 保護(hù)位在這里不是可選項是必須項否則形成遞歸過濾死循環(huán)。4.3 提示文本與輸入法狀態(tài)處理現(xiàn)代界面里常見的灰字提示Placeholder原生 EDIT 控件在經(jīng)典 Win32 下沒有直接屬性需要自己繪制或者用 EM_SETCUEBANNER 消息。EM_SETCUEBANNER 是 ComCtl32 6.0 之后才支持的XP 以后系統(tǒng)基本都有但項目如果還在用舊公共控件庫則無效。使用方式是一次性設(shè)置提示文本控件在空內(nèi)容且未聚焦時自動繪制灰色占位文字。// 設(shè)置空內(nèi)容提示文本 SendMessage(hEdit, EM_SETCUEBANNER, (WPARAM)TRUE, (LPARAM)L請輸入設(shè)備序列號);參數(shù)說明第一個參數(shù) TRUE 表示聚焦時提示也顯示直到開始輸入第一個字符FALSE 表示非聚焦時顯示、聚焦后立即消失。通常用 TRUE 反而更清楚因為用戶聚焦后看到提示消失會意識到“這里等我輸入”。另外EM_SETCUEBANNER 設(shè)置后不會影響文本內(nèi)容的讀取GetWindowText 拿到的仍是空字符串這個行為需要業(yè)務(wù)邏輯配合——若要判斷用戶是否填了內(nèi)容應(yīng)該判斷 GetWindowText 的長度而不是讀提示文本。IME 輸入法的處理是容易被忽略的一塊。在程序化設(shè)置文本或清空編輯框后可能需要用 ImmAssociateContext 處理輸入法上下文。典型坑是用戶用中文輸入法輸入拼音這時你 SetWindowText 清空編輯框輸入法組合窗口還掛在那個控件上用戶繼續(xù)打字會出現(xiàn)下劃線文字殘留在框上。這種情況先發(fā) WM_IME_COMPOSITION 相關(guān)消息或者用 ImmNotifyIME 通知提交/取消當(dāng)前組合。// 清空編輯框時主動取消輸入法組合狀態(tài) HIMC hImc ImmGetContext(hEdit); if (hImc) { ImmNotifyIME(hImc, NI_COMPOSITIONSTR, CPS_CANCEL, 0); ImmReleaseContext(hEdit, hImc); } SetWindowText(hEdit, L);這段代碼里的 ImmNotifyIME 把當(dāng)前輸入法的拼音組合狀態(tài)清理掉然后再清空文本不會留下未提交的拼音殘影。注意 ImmReleaseContext 是配套操作獲取了就必須釋放否則輸入法上下文句柄泄漏輸入法相關(guān)功能在后續(xù)使用中會越來越卡頓。5. EDIT控件避坑手冊5個反復(fù)出現(xiàn)的真問題5.1 多行編輯框文本超長后 UI 卡死現(xiàn)象向多行 EDIT 控件追加大量文本每一行用 AppendText 方式 SetWindowText 累加程序在運(yùn)行幾分鐘后界面假死CPU 占用極高。原因每次 SetWindowText 都會觸發(fā)控件完全重排文本、通知父窗口、重繪整個客戶區(qū)。當(dāng)文本行數(shù)上千時一次寫入觸發(fā)的是全量布局計算卡頓隨時間放大。解決批量寫入把多個日志行拼成一個大字符串一次寫入或者用 EM_GETHANDLE / EM_SETHANDLE 直接交換系統(tǒng)分配的內(nèi)存塊。日志型業(yè)務(wù)的合理做法是控制總行數(shù)超過閾值就裁剪掉最早的若干行只保留最近的內(nèi)容。void AppendLog(const CString line) { CString current; m_editLog.GetWindowText(current); current line L\r\n; if (current.GetLength() MAX_LOG_LEN) { current current.Right(MAX_LOG_LEN); } m_editLog.SetWindowText(current); }這個寫法是性能可接受的最簡方案。每次寫入讀全量再寫全量數(shù)據(jù)量控制在 32KB 以內(nèi)完全可用如果日志超過 100KB 才需要考慮 SETHANDLE 方案。另一種替代是使用 ListBox 或 ListView 做日志區(qū)域它們在行數(shù)管理上比 EDIT 控件原生得多但那已經(jīng)不是 EDIT 控件的用法了。5.2 密碼框顯示明文一閃而過現(xiàn)象密碼編輯框在窗口刷新的瞬間能看到真實(shí)密碼窗口切換再切回時內(nèi)容短暫可見。原因ES_PASSWORD 的掩碼機(jī)制在控件繪制時生效但如果設(shè)置了 EM_SETPASSWORDCHAR 時機(jī)太晚或者對話框初始化里先 SetWindowText 再設(shè)置掩碼字符會在掩碼生效前完成一次繪制。重啟刷新時系統(tǒng)窗口重繪也有類似窗口期。解決在 OnCreate 或 OnInitDialog 里先設(shè)置好 EM_SETPASSWORDCHAR 和樣式然后再寫入初始文本。如果是動態(tài)創(chuàng)建把創(chuàng)建、設(shè)密碼樣式、傳初始文本放到同一條代碼路徑連續(xù)執(zhí)行中間不要給消息循環(huán)讓出時間片。// 正確順序先樣式后內(nèi)容 HWND hPwd CreateWindow(LEDIT, L, WS_CHILD | WS_VISIBLE | WS_TABSTOP | ES_PASSWORD, x, y, w, h, hParent, (HMENU)IDC_EDIT_PWD, NULL, NULL); SendMessage(hPwd, EM_SETPASSWORDCHAR, (WPARAM)L●, 0); SetWindowText(hPwd, Ldefault_password);注意 EM_SETPASSWORDCHAR 的 wParam 是掩碼字符的字符碼傳 0 會恢復(fù)默認(rèn)的星號。使用圓形黑點(diǎn)作為掩碼是更常見的現(xiàn)代風(fēng)格字符可以直接傳 L●。5.3 EN_CHANGE 事件在程序?qū)懭霑r也被觸發(fā)現(xiàn)象在 CHECKBOX 的點(diǎn)擊事件里通過 SetWindowText 給 EDIT 控件寫內(nèi)容結(jié)果 EN_CHANGE 里的業(yè)務(wù)邏輯被重復(fù)執(zhí)行數(shù)據(jù)被疊加處理。原因EN_CHANGE 不只響應(yīng)用戶鍵盤輸入任何對控件文本的修改包括程序性 SetWindowText、SendMessage(WM_SETTEXT)、甚至撤銷重做都會觸發(fā)。解決程序性寫入時加防重入標(biāo)志。注意這個標(biāo)志必須在寫入前設(shè)置、寫入完成后清除且寫入過程中可能觸發(fā)的所有分支都要復(fù)位標(biāo)志防止標(biāo)志卡在 TRUE 導(dǎo)致后續(xù)所有用戶輸入不響應(yīng)。void SetEditInProgram(HWND hEdit, const wchar_t* text) { g_bProgrammaticUpdate TRUE; SetWindowText(hEdit, text); g_bProgrammaticUpdate FALSE; } // EN_CHANGE 處理器里 if (g_bProgrammaticUpdate) return;5.4 Tab 順序錯亂導(dǎo)致焦點(diǎn)飛走現(xiàn)象對話框里多個編輯框運(yùn)行后按 Tab 無法按預(yù)期順序切換焦點(diǎn)會跳到奇怪的控件上或者停在某個編輯框里出不來。原因?qū)υ捒蚰０謇锟丶穆暶黜樞驔Q定 Tab 順序但動態(tài)創(chuàng)建的控件默認(rèn)排在末尾即使它在屏幕上位置在最前面。樣式里漏掉 WS_TABSTOP 也會導(dǎo)致跳過該控件。解決動態(tài)創(chuàng)建全部完成后用 SetWindowPos 或者 SetWindowLong 調(diào)整 Z 序?qū)υ捒蚰０鍎t在資源文件里調(diào)整控件聲明順序。一個快捷做法是通過 GetNextDlgTabItem 手動控制 Tab 焦點(diǎn)。// 手動控制 Tab 跳轉(zhuǎn)順序 HWND hNext GetNextDlgTabItem(hDlg, hCurrentEdit, FALSE); if (hNext) SetFocus(hNext);這里的第三個參數(shù) FALSE 表示按 Tab 正向查找TRUE 是反向。使用這段代碼的前提是你已經(jīng)確認(rèn)了當(dāng)前焦點(diǎn)控件是誰通常在 EN_SETFOCUS 通知里做記錄。5.5 編輯框背景色與文字色設(shè)置后出現(xiàn)閃爍現(xiàn)象通過 WM_CTLCOLOREDIT 設(shè)置了自定義背景色輸入時文字高亮區(qū)域出現(xiàn)大面積白色閃爍每次擊鍵都閃。原因WM_CTLCOLOREDIT 返回的畫刷句柄在控件重繪時被臨時使用系統(tǒng)需要擦除背景再繪制新內(nèi)容當(dāng)畫刷每次都是新建而不是緩存時擦除和繪制頻率不一致導(dǎo)致閃爍。消息處理函數(shù)里沒做雙緩沖系統(tǒng)默認(rèn)的擦除重繪流程在編輯框這種密集重繪的控件上尤其明顯。解決把畫刷對象做成靜態(tài)或成員變量緩存WM_CTLCOLOREDIT 里每次都返回同一個 HBRUSH。同時如果項目允許調(diào)用 SetClassLong 設(shè)置類的背景畫刷也可以但注意這個影響的是整個窗口類的背景不是單控件的。case WM_CTLCOLOREDIT: { // 使用緩存的畫刷避免每次重建 static HBRUSH hBrushEdit CreateSolidBrush(RGB(255, 255, 240)); SetTextColor((HDC)wParam, RGB(60, 60, 60)); SetBkColor((HDC)wParam, RGB(255, 255, 240)); return (LRESULT)hBrushEdit; }這段代碼的 wParam 是子控件提供的 HDC通過 SetTextColor 和 SetBkColor 設(shè)置文字色和背景色后返回畫刷句柄給系統(tǒng)。畫刷對象是 static 的生命周期跟隨消息回調(diào)避免每次重繪都重新創(chuàng)建 GDI 對象。背景色和文字色的 RGB 值可以根據(jù)界面主題調(diào)整注意 SetBkColor 和 SetTextColor 的調(diào)用順序不影響結(jié)果但必須確保背景色和返回的畫刷顏色一致否則控件邊框處會出現(xiàn)顏色不閉合的縫隙。6. 進(jìn)階自繪與消息劫持的線路圖真正把 EDIT控件用到極致是繞過它的默認(rèn)行為、按業(yè)務(wù)目標(biāo)改寫交互方式。兩條主流路線子類化Subclassing和超類化Superclassing。子類化是用 SetWindowLongPtr 把目標(biāo)控件的窗口過程替換成自己的過程函數(shù)在自定義過程里處理完特定消息后把不感興趣的消息交給原窗口過程。這條路線能實(shí)現(xiàn)的效果包括自動補(bǔ)全文本的候選列表、輸入時屏蔽粘貼操作、按回車自動擴(kuò)展到下一行等。// 子類化替換編輯框消息處理 WNDPROC g_pOldEditProc; LRESULT CALLBACK CustomEditProc(HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam) { if (msg WM_CHAR) { // 攔截 A-Z自動轉(zhuǎn)大寫 if (wParam La wParam Lz) { wParam - 32; // 轉(zhuǎn)換成大寫 } } else if (msg WM_PASTE) { // 禁止從剪貼板粘貼 return 0; } // 其余消息交給原始過程 return CallWindowProc(g_pOldEditProc, hWnd, msg, wParam, lParam); } // 安裝子類化 HWND hEdit GetDlgItem(hDlg, IDC_EDIT_CODE); g_pOldEditProc (WNDPROC)SetWindowLongPtr(hEdit, GWLP_WNDPROC, (LONG_PTR)CustomEditProc);這段子類化代碼用到 SetWindowLongPtr 的 GWLP_WNDPROC注意保存原窗口過程指針在自定義過程里通過 CallWindowProc 轉(zhuǎn)發(fā)。WM_CHAR 里 wParam 是大寫字母字符碼攔截它在用戶鍵入時就轉(zhuǎn)換WM_PASTE 返回 0 直接拒絕粘貼這是實(shí)現(xiàn)受限邏輯不允許從外部粘貼亂碼的常用策略。子類化的解除用 SetWindowLongPtr 把原過程裝回去窗口銷毀前必須解除否則窗口銷毀時訪問已釋放的過程地址會崩潰。超類化則是注冊一個基于 EDIT 類的新窗口類在新類的窗口過程里處理前置和后置邏輯。好處是同一窗口類可以創(chuàng)建多個實(shí)例且不需要逐個窗口去綁定過程實(shí)現(xiàn)上需要自己動手注冊類// 超類化基于 EDIT 注冊新類 WNDCLASS wc {0}; GetClassInfo(NULL, LEDIT, wc); // 拿到原始類信息 wc.lpszClassName LSuperEdit; // 新類名 wc.lpfnWndProc SuperEditProc; // 新窗口過程 RegisterClass(wc); // 創(chuàng)建時使用新類名 HWND hEdit CreateWindow(LSuperEdit, L, ...);超類化有個關(guān)鍵約束必須先 GetClassInfo 拿原始類的信息做基底然后改類名和窗口過程再注冊。窗口過程里同樣需要保存一個系統(tǒng)默認(rèn) EDIT 過程的地址因為此時類信息里的 lpfnWndProc 已經(jīng)被你覆蓋原始地址從 GetClassInfo 時就已經(jīng)保存在全局變量里。兩種路線選哪個如果只有一兩個編輯框需要特殊行為子類化更輕量如果整個項目里編輯框都有統(tǒng)一的增強(qiáng)需求——比如統(tǒng)一輸入法狀態(tài)管理、統(tǒng)一顏色方案——超類化更省事一處注冊全局生效。最后一條經(jīng)驗調(diào)試編輯框交互的時候不要用 MessageBox 彈窗打印內(nèi)容因為彈窗會打斷消息順序?qū)е?EN_CHANGE 不到、焦點(diǎn)錯亂、輸入法死鎖。用 OutputDebugString 或者直接寫日志文件消息循環(huán)保持暢通才能看到真實(shí)行為。這套從創(chuàng)建、讀寫、樣式到消息劫持的完整鏈路跑通以后你會發(fā)現(xiàn)所謂編輯框的問題大多是消息時序和樣式組合的問題和控件本身好不好用關(guān)系不大。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取