WM_ACTIVE的消息参数

wParam的低阶word指示窗口是被激活还是失去激活：

WA_ACTIVE，被鼠标点击以外的方法激活；

WA_CLICKACTIVE，由鼠标点击激活；

WA_INACTIVE，失去激活；

wParam的高阶word指示窗口是否被最小化；

非零表示最小化；

lPararm表示将激活的窗口句柄(WA_INACTIVE)，或者将失去激活的窗口句柄(WA_CLICKACTIVE、WA_ACTIVE)。

在标准Windows消息处理的章节中，曾指出处理WM_ACTIVE消息时，先要调用一个函数_AfxHandleActivate，此函数的原型如下：

　　static void AFXAPI _AfxHandleActivate(CWnd* pWnd,

　　WPARAM nState,CWnd* pWndOther)

　　其中：

　　参数1是接收消息的窗口；

　　参数2是窗口状态，为WM_ACTIVE的消息参数wParam;

　　参数3是WM_ACTIVE的消息参数lParam表示的窗口。

　　_AfxHandleActivate是MFC内部使用的函数，声明和实现均在WinCore.CPP文件中。实现如下：

　　如果pWnd指向的窗口不是子窗口，而且pWnd和pWndOther窗口的顶级父窗口(TopLevelParent)不是同一窗口，则发送MFC定义的消息WM_ACTIVATETOPLEVEL给pWnd的顶级窗口，消息参数wParam是nState，消息参数lParam指向一个长度为二的数组，数组里存放pWnd和pWndOther所指窗口的句柄。否则，_AfxHandleActivate不作什么。

　　从这里可以看出：只有顶层的主边框窗口能处理WM_ACTIVE消息，事实上，Windows系统只会给顶层的非子窗口发送WM_ACTIVE消息。

　　WM_ACTIVATETOPLEVEL消息的处理

　　CWnd及派生类CFrameWnd实现了对WM_ACTIVATETOPLEVEL消息的处理，分别解释如下：

　　消息处理函数CWnd::OnActivateTopLevel如果失去激活，则取消工具栏的提示（TOOLTIP）。

　　消息处理函数CFrameWnd::OnActivateTopLevel调用CWnd的OnActivateTopLevel；如果接收WM_ACTIVE消息的窗口是线程主窗口，则使得其活动的视窗口变成非活动的（OnActive(FALSE, pActiveView,pActiveView)。

　　从这里可以知道，在顶层窗口接收到WM_ACTIVE消息后，MFC会进行一些固定的处理，然后才调用WM_ACTIVE消息处理函数。

　　WM_ACTIVE消息的处理

　　在_AfxHandleActivate和WM_ACTIVATETOPLEVEL消息处理完之后，才是对WM_ACTIVE的处理。CWnd和CFrameWnd都实现了消息处理。

　　CWnd的消息处理函数：

　　void CWnd::OnActive(UINT nState, CWnd* pWndOther, BOOL bMinimized)

　　其中：

　　参数1取值为WA_INACTIVE/WA_ACTIVE/WA_CLICKACTIVE；

　　参数2指向激活或者失去激活的窗口，具体同WM_ACTIVE消息；

　　参数3表示是否最小化。

　　此函数的实现是调用Default()，作缺省处理。

　　CFrameWnd的消息处理函数：

　　void CFrameWnd::OnActive(UINT nState,CWnd* pWndOther, BOOL bMinimized)

　　首先调用CWnd::OnActivate。

　　如果活动视非空，消息是WA_ACTIVE/WA_CLICKACTIVE，并且不是最小化，则重新激活当前视，调用了以下函数：

　　pActiveView->OnActiveView(TRUE，pActiveView，pActiveView)；

　　并且，如果活动视非空，通知它边框窗口状态的变化（激活/失去激活），调用以下函数：

　　pActiveView->OnActivateFrame(nState, this)。

转自：
http://blog.csdn.net/iu_81/archive/2007/09/27/1803817.aspx

最近写了点C++的代码,其中也出现过很多奇怪的错误,heap corruption detected就是其中之一,而且这种错误很容易出现,一般出现该错误,在debug中都有大致如下的错误信息:

heap corruption detected:
after normal block(#xxx) at 0x xxxxxxxx
crt detected that the application wrote to menory after end of heap buffer

这是典型的内存溢出错误,常在内存的delete处发生,而且一般在debug版本中可能出现,release版本中可能并不报错.

出现这个错误的原因一般都是操作new申请的内存溢出,因为在c++中,如果用new分配一段内存,操作的时候改变了该部分的大小,在delete时就会出错.比如说如下部分:
char* p=new char[5];
strcpy(p,"aaaaa");
delete[] p;
这段代码就会出错,因为申请了一个size为5的内存,但是strcpy过去了一个size为6的字符串,因此破坏了这个指针,运行debug版本的时候就会出现先前的错误,但是在release版本中,溢出一个字节的内存很有可能是没有错误的,然后潜在的隐患是肯定存在的,因此,我们在debug遇到这样的错误时候一定要仔细检查对new出的指针的操作.

我的环境是: XP SP2 . VS2003

最近在一个项目中,程序退出后都出现内存泄漏:

Detected memory leaks!
Dumping objects ->
{98500} normal block at 0x05785AD0, 152 bytes long.
Data: << N       N x 7 > 3C AC 4E 10 00 00 00 00 BC A4 4E 10 78 B6 37 00
Object dump complete.

而且每次退出都是一样的.泄漏的内存块都是98500.

解决方法:

1. 在程序开始启动的地方(足够前的地方,只要在泄漏的内存分配的前面)使用代码:

_CrtSetBreakAlloc(98500); //98500为上面内存泄漏的块号.

2. 然后debug运行,程序自动断点在"内存块98500"分配的位置:

/* break into debugger at specific memory allocation */

if (_crtBreakAlloc != -1L && lRequest == _crtBreakAlloc)
_CrtDbgBreak();

3 .我们已经找到了泄漏的那块内存分配的底层操作的地方了(好拗口!).

这个时候我们利用 "调试" –> "退出" ,快捷键为:"Shift + F11" .

跳出当前函数..然后一直往"上"跳,边跳边查看调用栈.直到看到了自己写的代码,例如我的

std::ifstream* origStream = new std::ifstream();

4 .这个时候我已经可以判断 origStream 分配了内存,但是没有合理释放.处理后再次运行就没有出现内存泄漏了.

5.最后,记得把_CrtSetBreakAlloc(98500); 这句话删除掉,不然每次都断点,岂不是烦死..

----------------------------------------------------------------------------------------------------------

写在后面:

关于内存泄漏检测,有一个Visual Leak Detector ,按照它的介绍的确很不错,可以直接具体到代码行指出内存泄漏,但是个人使用了一下,发现debug的速度太慢了,不知道是不是我个人程序的问题.......像上面的泄漏,我用CrtSetBreakAlloc这种简单的方法就足够了....

By: 洪庚伟