Earlier, I discussed
which window style bits belong to whom.
One detail of this that I neglected to emphasize is that
lower 16 bits of the window style are defined by the class,
you can't just take styles from one class and apply them to another.
For example, you can't create a button control and pass the
SS_ENDELLIPSIS style expecting to have the text
rendered with end ellipses.
Because when you think you're passing
you're really passing
#define SS_ENDELLIPSIS 0x00004000L #define BS_NOTIFY 0x00004000L
The button control sees your 0x00004000L and treats it as
Remember that at the end of the day, window styles and window messages are just numbers. If you use a per-class window style or window message, you'd better be passing it to the class that defined it.
This also applies to window extra bytes.
The value returned by
is meaningful only if
hwnd is a dialog box.
I've seen code by a major commercial software manufacturer
that just runs around fiddling with the
of every window on the desktop on the assumption that
"Why of course it's a dialog box, why do you ask?"
Well, except that
DWLP_DLGPROC has the numerical value of 4
(or 8 on Win64).
Positive window byte indices are class-defined.
DWLP_DLGPROC of a random window
will give you the dialog procedure if that window is a dialog box,
but it'll return some other internal data if the window isn't.
Fortunately, most window classes don't ask for more than
sizeof(void*) extra bytes, so the
DWLP_DLGPROC just fails with an
invalid parameter error.
But if there happened to be a window belonging to a class with
a larger number of extra bytes,
that window will be in for quite a surprise when that rogue
program comes in and starts messing with those extra bytes.