处理Rich Edit控件WM_NOTIFY消息时，如何获取变更信息及明确lParam指向结构？

这其实是Windows消息机制里一个很典型的「通用+扩展」设计，我给你拆解明白：

首先明确两个核心点：

• 所有WM_NOTIFY消息的lParam，底层都是指向NMHDR结构的——这是所有通知消息的「通用头部」，里面存着发送通知的控件句柄、ID，还有最关键的通知码（比如你说的EN_CHANGE）。
• 像EN_CHANGE这类Rich Edit的特定通知，会使用以NMHDR为第一个成员的扩展结构（也就是CHANGENOTIFY）。

为什么会有这种看似矛盾的文档说明？因为CHANGENOTIFY的内存布局是这样的：它的第一个字段就是NMHDR，所以当lParam指向CHANGENOTIFY时，你既可以把它当作NMHDR来读取通用信息，也可以在确认通知码后，把它转换成CHANGENOTIFY来获取变更相关的细节。

给你举个实际处理的代码例子（C++）：

case WM_NOTIFY:
{
    // 先按通用NMHDR来解析，确认通知类型
    NMHDR* pNMHDR = reinterpret_cast<NMHDR*>(lParam);
    if (pNMHDR->code == EN_CHANGE)
    {
        // 确认是EN_CHANGE后，转换为CHANGENOTIFY获取变更详情
        CHANGENOTIFY* pChangeInfo = reinterpret_cast<CHANGENOTIFY*>(lParam);
        
        // 比如判断变更类型：插入、删除、格式修改等
        if (pChangeInfo->dwChangeType & CFI_INSERTTEXT)
        {
            // 处理文本插入的逻辑
        }
        else if (pChangeInfo->dwChangeType & CFI_DELETETEXT)
        {
            // 处理文本删除的逻辑
        }
    }
    break;
}

简单总结一下处理流程：

1. 收到WM_NOTIFY时，先把lParam转成NMHDR*，读取code字段判断是哪种通知。
2. 如果是EN_CHANGE，再把同一个lParam转成CHANGENOTIFY*，就能拿到变更的具体信息（比如变更类型、影响的范围等）。

这种设计的好处是统一了所有通知消息的处理入口——不管是什么控件的什么通知，你都可以先通过NMHDR做初步判断，再按需转换到特定结构，逻辑更清晰也更容易扩展。

内容的提问来源于stack exchange，提问作者Ivan Venkov