According to the API documentation every window comes with a 32 bit value at offset GWL_USERDATA that is intended for use by applications. Nonetheless, many windows programmers allocate an extra DWORD of window memory by setting the WNDCLASS cbWndExtra to 4.

I have always followed that convention, being unsure whether there is a good reason for ignoring the memory at the GWL_USERDATA offset. Anyone has a good reason?

It's kind of like how sample code sometimes shows



PAINTSTRUCT ps;

HDC hdc;

hdc = BeginPaint(hwnd, &ps)

Draw(hdc);



Instead of:



PAINTSTRUCT ps;

BeginPaint(hwnd, &ps);

Draw(ps.hdc);



The former is redundant but you see it so often.
Why store the BeginPaint return value when its already in ps?

BTW, please excuse my C-like Pseudocode ;)
Posted on 2002-09-29 16:37:36 by Thanatos

I have always followed that convention, being unsure whether there is a good reason for ignoring the memory at the GWL_USERDATA offset. Anyone has a good reason?


GWL_USERDATA is, like it's name says, user data so you can do whatever you want with it. The extra window bytes work the same way, it's just that GWL_USERDATA is included by default.

The former is redundant but you see it so often. Why store the BeginPaint return value when its already in ps?


BeginPaint always returns the HDC, whether you use it or not. Using ps.hdc forces the compiler (in case of C code) to read from the ps.hdc memory location. It would probably put it in a non-volatile register (if available) like ebx, esi or edi and use that as DC handle. As BeginPaint returns the HDC in eax anyway, using eax is faster than reading ps.hdc... Although I think most C programmers use the local HDC variable for readability instead of optimization (the ones that don't know asm at least :))...

Thomas
Posted on 2002-09-29 17:21:55 by Thomas
If the compiler makes HDC a stack variable there is no gain though.
Posted on 2002-09-29 18:36:29 by Thanatos