LVN_GETDISPINFO通知能否放在CListCtrl子类处理而非父窗口？

关于通知接收方的差异说明 #

原生Win32的控件通知WM_NOTIFY默认确实会发送给控件的父窗口，微软官方文档描述的是原生Win32的底层行为，你在MFC项目里看到的CListCtrl子类能处理LVN_GETDISPINFO，是MFC框架自带的消息反射机制导致的：MFC会把父窗口收到的子控件通知消息先反射回子控件自身，如果子控件实现了对应的消息处理函数，就会优先被子控件消费，父窗口后续就不会再收到该通知，这是MFC对原生Win32消息机制的扩展封装，和官方文档的描述并不冲突。

架构合理性与方案优势 #

把LVN_GETDISPINFO处理逻辑放在CListCtrl子类中是非常合理的架构设计，相比父窗口处理的标准方案有这些优势：

• 封装性更强：虚拟列表的数据查询逻辑和控件本身绑定后，该控件就成为了自包含的可复用组件，不需要依赖父窗口的逻辑实现，直接在任意父窗口中嵌入即可使用，符合面向对象的封装原则。
• 代码复用率更高：如果项目中存在多处需要用到同规则虚拟列表的场景，直接复用该CListCtrl子类即可，不需要在每个父窗口中重复编写LVN_GETDISPINFO的处理代码，大幅减少冗余代码。
• 职责划分更清晰：父窗口的核心职责是管理其下所有子控件的全局交互逻辑，不需要感知单个控件的内部数据加载细节。数据逻辑放在控件子类中后，父窗口仅需要调用控件暴露的公开方法（比如SetDataSource）传入数据即可，代码职责拆分明确，可维护性更高。
• 避免父窗口代码膨胀：如果父窗口中存在多个虚拟列表控件，所有通知处理逻辑都放在父窗口中会导致父窗口代码臃肿混乱，逻辑分散到各自的控件子类中后，代码结构会更加清晰，排查问题也更高效。

内容的提问来源于stack exchange，提问作者Serge Roussak