Why is the idFrom field in the NMHDR struct a UINT_PTR type? Control identifiers are 16-bit unsigned.

Question

Can I assume that all control identifiers will fit in an unsigned 16-bit field for the WM_NOTIFY message?

I have the same question about control notification codes even though the NMHDR uses a

32-bit integer for the codes. This is true for WM_COMMAND messages since the HIWORD and

LOWORD macros are used to extract the id and code from the WPARAM argument of the message.

Thank you.

Answer 1

It’s because it the address of the unsigned int value, not the value itself. With a 32 bit app it’s 32 bits, with a 64 bit app, it’s 64 bits.

Answer 2

Assuming that a control id will always be a 16-bit value carries some risk. Refer to the following which also discusses why provision is made for both 32-bit and 64-bit values.

Why are timer IDs and dialog control IDs 64-bit values on 64-bit Windows? Did you really expect people to create more than 4 billion timers or dialog controls

Answer 3

There is no documentation stating that a child window ID must be unsigned 16 bits. In fact, since the ID goes in through the HMENU parameter, it is possible for the ID to be 64 bits. The documentation only specifies that this is an integer. The documentation for Windows Features also states that this identifier is an integer.

Another thing to remember is that you do not need to get the control ID from the wParam low word. The lParam parameter is a handle to the control itself. So, what is stopping you from using GetWindowLongPtr with GWLP_ID to obtain the control ID?