I noted in the bonus chatter that if you have a control whose ID is IDCANCEL, it had better be a button if you know what’s good for you. Shawn Keene doesn’t know what’s good for him and asks, “I can’t wait to find out what happens if my control is not a button.”

What happens is that the dialog manager will generate a WM_COMMAND message as if your IDCANCEL control were a button, even if it isn’t.

This means that the message arrives with a notification code of BN_CLICKED, a control ID of IDCANCEL, and a window handle of your not-actually-a-button window.

Since your control is not actually a button, it will treat the BN_CLICKED as if it were a notification appropriate to its type. The numeric value of BN_CLICKED is zero, so it’ll be treated as whatever a notification code of zero means for that control type. For example, if it’s actually a static control, you’ll interpret the zero to mean STN_CLICKED.

If it’s actually a list box, then you’ll see the zero and say “Huh? I don’t see any notification code with the numeric value of zero. What’s going on?”

If it’s a custom control, you will interpret the zero as whatever that custom control defines notification code zero to mean.

Basically, what you did is signed yourself up for confusion. You’re going to get a WM_COMMAND message with BN_CLICKED as the notification code, IDCANCEL as the control ID, and your non-button window as the control. What you do with that information is up to you.

Bonus reading: Why do dialog editors start assigning control IDs with 100?