之前我在一篇文章中曾經提過，不應該利用 WM_KILLFOCUS 消息中對表單的字段進行有效性校驗。 今天的文章，我將介紹另外一個反面例子，來表現當使用 WM_KILLFOCUS 消息處理焦點相關的問題時所帶來的混亂。

假設，有一個編輯框控件使用了氣球提示來顯示反饋信息。舉個例子，對于一個密碼輸入控件，當鍵盤上的 CapsLock 按鍵按下時，它會提示用戶，以防止用戶輸入錯誤的密碼。作為開發者，你可能希望，當用戶將輸入焦點從密碼輸入框移動到另外一個控件時，將氣球提示移除，這是合情合理的。因為向用戶給出一個他完全不會使用到的控件提示，會讓用戶感到莫名其妙。可以通過對輸入控件子類化來實現上述的需求，如下圖所示：

使用上面的代碼進行初步測試，一切如預期般正常工作，只是有一個問題：當用戶點擊氣球提示時，編輯框的輸入光標會意外的消失，這是為啥？

發生的事情是，你通過破壞焦點要去的窗口來破壞焦點變化過程！焦點更改過程如下所示：

• 將焦點移動至新的窗口。
• 發送 WM_KILLFOCUS 消息給丟失焦點的窗口（如果有的話） 發送 WM_SETFOCUS 消息給新的焦點窗口（如果有的話）

但是在上面的第二步，我們銷毀了新的窗口。當焦點窗口被銷毀后，Windows 窗口管理器會嘗試找另外一個焦點窗口，最終它將輸入焦點設置到了輸入框控件本身。這將啟動一個遞歸式的焦點更改過程，告知編輯控件它現在再次具有輸入焦點。

讓我們看一下當用戶單擊工具提示窗口時焦點變化流程。

• > 設置焦點到工具提示。
• > 發送 WM_KILLFOCUS 消息到輸入框。
• > EditSubclass 銷毀了工具提示窗口。
• > Windows 窗口管理器將焦點設置到輸入框。
• > WM_KILLFOCUS 不會發送給任何窗口。
• > 發送 WM_SETFOCUS 給輸入框。
• > EditSubclass 將 WM_SETFOCUS 消息傳遞給原始窗口過程。
• > EditSubclass 將 WM_KILLFOCUS 傳遞給原始窗口過程。

你看到這里面的問題了嗎？

下面是到達原始編輯框窗口過程的消息流程：

WM_SETFOCUS(源自嵌套的焦點變化過程） WM_KILLFOCUS(源自原始的焦點變化過程)

就編輯控件而言，它獲得了焦點，然后失去了焦點。因此，它不會顯示輸入光標，因為編輯控件僅在具有焦點時才顯示光標，并且遞歸焦點變化會導致編輯控件認為它沒有焦點，即使它有焦點。

擺脫這種混亂的方法有很多。

首先，請注意，你不需要對編輯控件進行子類化，你可以對 EN_KILLFOCUS 通知做出反應。其次，你還可以通過向自己發布消息并在收到該發布消息后銷毀工具提示來響應 EN_KILLFOCUS。通過發布的消息執行此操作，你可以避免遞歸焦點變化，因為你的工作現在正在焦點更改周期之外完成的。

總結 請不要忽視這些細枝末節的問題，資深用戶會感受到你的程序里的各種細節。 如果是好的細節，你的程序會加分，萬一是不那么好的細節，那就不是一件好玩的事兒了，你的用戶會慢慢離你而去。