Message loop not working...

Oh shoot, I hate it when I do this sort of thing Everything works fine and as expected if I check for WM_COMMAND and WM_CLOSE in the dialog procedure, although for some reason it doesn't work when I check in the message loop. The reason I checked in the message loop was to avoid using yet another global variable, but in this case I can't see how to avoid it Any ideas, or should I just get on with my life and leave the global variable there?

I encountered this a while ago.
It turns out WM_CLOSE (and others) is a sent message. This means Windows calls your Window Proc directly. It will not be returned by GetMessage. The last message you get is something like WM_NCLBUTTONUP. After this when you call GetMessage Windows takes the opportunity to call your Window Proc directly with WM_CLOSE.

Originally posted by Hunter2
Oh shoot, I hate it when I do this sort of thing Everything works fine and as expected if I check for WM_COMMAND and WM_CLOSE in the dialog procedure, although for some reason it doesn't work when I check in the message loop. The reason I checked in the message loop was to avoid using yet another global variable, but in this case I can't see how to avoid it Any ideas, or should I just get on with my life and leave the global variable there?

Never check for messages in the message loop; ALWAYS check in the window procedure. The window procedure's mission in life is to respond to messages; this is where messages should be handled, without exception.

As to ways around a global variable, you can use the UserData long in the window to store information, see GetWindowLongPtr() and SetWindowLongPtr() for info.

Wow, thanks a bunch! I never knew Windows had a UserData to use. Except, shouldn't it be GetWindowLong() instead of GetWindowLongPtr()?

Originally posted by Hunter2
Wow, thanks a bunch! I never knew Windows had a UserData to use. Except, shouldn't it be GetWindowLong() instead of GetWindowLongPtr()?

GetWindowLongPtr() replaces GetWindowLong(). Compiled for 32-bit systems they have the same effect. But GetWindowLongPtr() and SetWindowLongPtr() are the newer and recommended way to access the window data because they are compatible with 64-bit versions of Windows. SetWindowLong() can only store 32 bits of data regardless; on Win32 this is OK, because pointers are 32 bits, but under Win64, pointers are 64 bits.

SetWindowLongPtr() sets a 32 bit value under Win32, 64 bit value under Win64, so you should prefer it. Likewise with GetWindowLongPtr().

Odd, it gives me a compile error: undeclared identifier. Are you sure that I don't need any special include or something?

*EDIT*
Also, they don't appear in my MSDN when I type them in the index...

Probably an out-of-date library.

It's no big deal assuming you're writing for Win32 and don't care about Win64, you can just omit the -Ptr.

http://msdn.microsoft.com/library/de...dowLongPtr.asp

Oh ok, thanks. But what exactly is win64? Is it Windows NT and 2000?

Win64 is Windows for 64-bit CPUs. It's been around in the server world for a while, but XP is the first to offer a general 64-bit version for desktops. CPUs like the Itanium2 are 64-bit (as opposed to Athlon, Pentium, etc. which are 32-bit).

XP 64 allows you to have workstations with up to 16 gigs of RAM and 8 terabytes of virtual memory; the 16 GB limit will probably be relaxed in later OSs (e.g. Longhorn). Theoretically, a 64-bit machine could have 16.7 million terabytes (= 17.1 billion gigabytes) of memory.

It is backwards compatible (it can run Win32 applications), but Win32 applications will not be able to benefit from the large amount of RAM; the virtual memory space of the Win32 application would still be 4 GB, and no more.

The light dawns. Thanks for the explanation!