编写Win32 ListView派生的自定义窗口类时使用自定义(子)项绘制的最佳方法

编写Win32 ListView派生的自定义窗口类时使用自定义(子)项绘制的最佳方法,listview,winapi,custom-draw,Listview,Winapi,Custom Draw,在listview中实现自定义子项绘制的一般方法是在父类中处理NM_CUSTOMDRAW通知,并在父类中进行绘制 但是,我正在编写一个可重用的listview派生的窗口类,并且希望避免强制用户将通知反映到实例化的窗口中,无论它们在何处使用 我知道有两种方法可供选择,但都有缺点 1:注册两个自定义窗口类,一个是从listview派生的,另一个是实例化我的类的任何对象所使用的。第二个类只是创建自定义listview作为子窗口来截获所有通知,然后反映这些通知或将它们转发给其父窗口。 缺点是:我还需要将

在listview中实现自定义子项绘制的一般方法是在父类中处理NM_CUSTOMDRAW通知,并在父类中进行绘制

但是,我正在编写一个可重用的listview派生的窗口类,并且希望避免强制用户将通知反映到实例化的窗口中,无论它们在何处使用

我知道有两种方法可供选择,但都有缺点

1:注册两个自定义窗口类,一个是从listview派生的,另一个是实例化我的类的任何对象所使用的。第二个类只是创建自定义listview作为子窗口来截获所有通知,然后反映这些通知或将它们转发给其父窗口。 缺点是:我还需要将发送到外部控件的所有外部消息转发到内部控件,或者通过自定义窗口消息公开内部控件,类似于如何访问listview中的header控件。所有通知也必须转发到其父级

2:控件可以将其父窗口子类化,并在该阶段截获WM_NOTIFY消息。 缺点:这是一个坏主意,也是一种非常脆弱的做事方式

或者:3。继续要求通知反射


是否有更好的方式通知定制抽签,而不是进行完全定制抽签,或者是否有某种方法可以先进行完全自定义绘制并触发默认绘制,然后绘制显示自定义数据的列的内容?

只要使用SetWindowsSubClass API,对父级进行子分类并不可怕。例如,工具提示控件就是这样做的。这是一个很好的观点。似乎仍然有更好的方法可以做到这一点,而不必操纵容器。