WM_KILLFOCUS<\/CODE> message can create confusion.\n<\/P>\n\nConsider an edit control that displays feedback via a balloon tip.\nFor example, password edit controls often warn you if you’re typing\nyour password while CapsLock is in effect.\nOne of the things you probably want to do is to remove the balloon\ntip if the user moves focus to another control, since there’s no\npoint telling the user about a problem with something they aren’t\nusing.\nYou might be tempted to subclass the edit control and do\nsomething like this:\n<\/P>\n
\nLRESULT CALLBACK EditSubclass(\n HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam)\n{\n switch (uMsg) {\n …\n case WM_KILLFOCUS:\n if (hwndBalloonTip) {\n DestroyWindow(hwndBalloonTip);\n hwndBalloonTip = NULL;\n }\n break;\n …\n }\n return CallWindowProc(prevWndProc, hwnd, uMsg, wParam, lParam);\n}\n<\/PRE>\n\nWhen you give this code a shot, it works great…\nunless the user clicks on the balloon tip itself<\/STRONG>\nthe edit control’s caret (the blinking insertion point thingie) disappears.\nWhat happened?\n<\/P>\n\nWhat happened is that you gummed up the focus change process by\ndestroying the window that focus was going to!\nThe focus change process goes like this:\n<\/P>\n
\n- Put focus on new focus window.\n
- Send WM_KILLFOCUS to old focus window (if any).\n
- Send WM_SETFOCUS to new focus window (if any).\n<\/UL>\n
\nBut in the second step, we destroyed the new focus window<\/STRONG>.\nWhen the focus window is destroyed, the window manager tries to find a new\nfocus window, and it settles upon the edit control itself.\nThis starts a recursive focus change cycle,\ntelling the edit control that it now has focus again.\n<\/P>\n\nLet’s look at the flow in this nested focus change scenario\nwhen the user clicks on the tooltip window.\n<\/P>\n
\n- Put focus on tooltip.\n
- Send WM_KILLFOCUS to edit control.\n
\n - EditSubclass destroys the tooltip.\n
\n - Window manager puts focus on the edit control.\n
- Nobody to send WM_KILLFOCUS to.\n
- Send WM_SETFOCUS to edit control.\n