WM_NOTIFY and NM_CUSTOMDRAW - winapi

Question

When a NM_CUSTOMDRAW notification code is send by a WM_NOTIFY message to the parent of a control, the lParam parameter of this WM_NOTIFY message is the address of an NMCUSTOMDRAW structure, as written here :
http://msdn.microsoft.com/en-us/library/windows/desktop/ff919569(v=vs.85).aspx
On the otherhand, the lParam of a WM_NOTIFY message should be
A pointer to an NMHDR structure that contains the notification code and additional
information. For some notification messages, this parameter points to a larger
structure that has the NMHDR structure as its first member.
In many code examples, for the handler for WM_NOTIFY message, I see
LPNMLISTVIEW pnm = (LPNMLISTVIEW)lParam;
switch (pnm->hdr.code){ ....
But the question is, we don't know this lParam is a NMHDR structure or a NM_CUSTOMDRAW structure a proior, how could one cast lParam correctly? If the lParam is a just a NMHDR,
one should use LPNMHDR and pnm->code, isn't it?
Worse, different control use different type of structures: NMLVCUSTOMDRAW, NMTVCUSTOMDRAW, NMLVCUTTOMDRAW and NMTBCUSTOMDRAW. So what is the correct way to do at the beginning of a WM_NOTIFY handler, distinguish it is with a NM_CUSTOMDRAW or not, and decide the correct NMCUSTOMDRAW structure type.
When I read the article
http://msdn.microsoft.com/en-us/library/windows/desktop/ff919569%28v=vs.85%29.aspx
on MSDN, I can't understand some parts. For example,
CDRF_NOTIFYPOSTPAINT The control will send an NM_CUSTOMDRAW notification when the painting cycle for the entire control is complete. This occurs when dwDrawStage equals CDDS_PREPAINT.
When a control send an NM_CUSTOMDRAW notification when the painting cycle for the entire control is complete, this NM_CUSTOMDRAW should have dwDrawState equals CDDS_PREPOSTPAINT, isn't it?
Can someone explain what "This occurs when...." in the list of the meaning of return value in that MSDN article.

Answer 1

It is easy. The lParam pointer is both NMHDR* and NMLVCUSTOMDRAW* in the same time. If you look at how NMLVCUSTOMDRAW is defined you will see it starts with NMHDR member.
Having said that, you can reliably cast your LPARAM to anything of your choice: NMHDR*, NMCUSTOMDRAW*, NMLVCUSTOMDRAW*. If the notification is coming from listview, the message itself is WM_NOTIFY and NMHDR::code equals to NM_CUSTOMDRAW, then any and all of the three casts will be correct.
Think of NMLVCUSTOMDRAW as of a notification-specific extension of general purpose NMHDR.

Answer 2

The way Microsoft Windows structures it's structures is in a Plain Old Data format. As such, if I define:
struct A {
int a;
};
struct B {
A a;
int b;
};
struct C {
A a;
int c;
};
The layout of B in memory is actually two integers, the entire contents of A (an integer) then the entire contents of B (another integer). As such, it's safe to treat B like A in so far as I can get the a value and from the a member, determine whether my pointer is really of type B or type C. In the example you present NMHDR is the generic value (A) and NMLISTVIEW is the specific value (B or C). You test the hdr value (of type NMHDR) to see what type the lParam is and from that you cast it to the correct subtype. This is true for C and C++ Windows development.