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

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

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

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

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

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

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

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

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

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

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

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

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

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

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