In the WinAPI, there is the ListView control. This control may be adjusted to work in so called virtual mode when it doesn't hold any data. Instead, it queries this data from its parent window. At least, accordingly to the documentation.

I'm working currently on an old MFC-driven project. I am faced with a strange thing: the handler for the notification specified in the subject is placed in the CListCtrl successor class. That is, the list control sends the notifications to itself. And this works. Though, there is nothing surprising here at the technical point of view. Probably... But, on the other hand, why then is the parent window mentioned in the documentation as the notification receiver?

My question: whether this is architecturally the right idea to place the LVN_GETDISPINFO's handler in the list control class, not in the parent window class as the documentation says? Is there some advantages in this solution over the documented one?

CodePudding user response：

MFC has message reflection technique. (The same thing is available to ATL/WTL). The notification messages still arrive to the parent, but the parent reflects them to the controls, altering message code.

When you use a control without overriding its behavior and not subclassing it, the parent window is responsible for its behavior, as you use a generic control.

When you subclass controls to define more specific behavior, then it may be better to define message handing in the subclassed control, to prevent this spreading between control and its parent.

VCL, the UI framework available in Delphi and C Builder, does the same thing. It reflects notification messages from parent window to child control, transforming them into events in the child control classes. Events are fired by controls, controls are always subclassed by the framework, and notification messages are always handled as reflected internally.