《MFC鼠标移动实时提示信息框的自动消失功能实现》一文中，我提到了当提示框闪烁时，其实伴随着主窗口的激活状态的变化，提示框消失后，主窗口被激活，也阐述了自己的测试结果：我自己断点调试后发现，只要你创建了鼠标移动消息——WM_MOUSEMOVE，程序就会在该消息处多运行一次。原文《win32鼠标移动实时提示信息框的自动消失功能实现》

我详细讲解下过程：
我创建了一个MFC对话框工程，仅仅加入了一个对话框响应消息：

void CjiDlg::OnMouseMove(UINT nFlags, CPoint point)
{
	// TODO: 在此添加消息处理程序代码和/或调用默认值
	CPoint pt;
	pt.x=point.x;
	pt.y=point.y;
	CDialogEx::OnMouseMove(nFlags, point);
}

测试步骤：
首先设置断点，最好设两个以上，然后运行，切记此时不要把你的鼠标放到对话框内，你会发现，此时断点没有执行。这是肯定的。如果不懂请自己想。随后我们把鼠标移动到窗口客户区中，记住，必须是客户区，非客户区不会响应消息。此时断电会运行。然后你按F5键，不要用鼠标运行，你会发现会有窗体闪烁。然后程序代码一直会在WM_MOUSEMOVE消息中断电运行。随后，你把鼠标放到窗口之外，断点仅仅会在执行一次的鼠标移动消息。然后便不会再执行了。
解释原因：
当我们把鼠标放到了窗口客户区，鼠标就会效应消息函数，响应完之后，还会再想响应一次。我觉得应该是判断鼠标光标是否在窗口客户区。即窗体是否还有焦点。按照我们对一般消息处理函数的理解，运行完一遍之后，不会再运行了，可是WM_MOUSEMOVE消息不会，他需要对鼠标的焦点位置进行检测，响应完一遍之后就会继续响应。我们可以这么验证：
我们的鼠标一直在客户区中，你不断的断点运行，然后你突然把鼠标放出去，随后，接着断点运行，你会发现，程序断点仅仅会执行完这一次，就不会在执行了。
上一次的执行是因为鼠标的移动，而下一次的执行时因为，需要判断鼠标焦点的位置
以上仅仅个人观点