Why the window procedure's arguments?

[hutch--]

hamper,

The format of a WndProc style procedure is dictated by its function in the operating system design. First and foremost it is a system defined CALLBACK which means that the system expects the address passed to it as the CALLBACK location to accept 4 DWORD sized arguments that occur in the order HANDLE, MESSAGE WPARAM, LPARAM, the format itself being a leftover from 16 bit where you had to distinguish between a WORD sized argument and a signed LONG argument.

Now going backwards from a WndProc style procedure, you have a standard message loop that is again dictated by the OS which is primarily there for manually processing key strokes as it avoids the lag of a WndProc.

Windows is basically a message driven windowing system and to provide those facilities, Windows specifies the format of how a user defined window interacts with the operating system. The CALLBACK technique is common to many Windows techniques, WndProc, DialogProc, Subclass procs, system hooks and the like and it is how an application interfaces with the functionality provided by the OS.

[qWord]

adding 268435456 into the dwStyle

bad programming practices! Use the corresponding equate: WM_VISIBLE

it's pointless, silly and doesn't do anything[...]It only adds[...]local variables

a wise programmer prefers local variables, because it can be assumed that they are always cached.

I define a window procedure 'WndProc', reluctantly including the four arguments, even though they're all useless to me because I can get more information from examining the (global) msg structure variable msg directly

as already said, that won't work reliable! please read this article:About Messages and Message Queues

[sinsi]

a wise programmer prefers local variables...

Essential in a multi-threaded app. Globals need spinlocks and such.