1

EDIT: Delete code I'd pasted here. An error in my code was causing the behavior described (missing a break in a switch statement).

In a switch statement that handled the messages from GetMessage, I tossed in the integer values for a couple of messages that don't have aliases defined (using a list I found here: http://www.mazama.net/scheme/v12/w32message.scm) with message boxes that would pop if one of these messages was received. My expectation was that the unnamed messages were simply deprecated and would never show up.

I also tried some code under WM_ACTIVATE that was supposed to minimize the window if I clicked out of it. I messed something up, so the window minimizes itself as soon as it opens, but that's not what brought me here. As soon as the window opens and minimizes, the message box pops to tell me Windows sent message 9. If I dismiss it, the message box pops again.

So it got me wondering, does anyone know what event triggers that message? Or, for that matter, any of the integer values returned by GetMessage that don't have an alias? Everything I've found listing the Windows messages omits the same numbers as the link I posted above.

jmccracken
  • 53
  • 8
  • It looks like your `break` statements are all out of their respective case blocks. –  Nov 09 '14 at 01:19
  • @hosch250 You're right; I was missing the `break` from the portion of the `switch` statement directly above the one that was supposed to pop a message box, so WndProc wasn't actually receiving that message. Don't know how I missed that. Leaving the question up for the answer below. – jmccracken Nov 09 '14 at 02:30

1 Answers1

2

Low-numbered messages that aren't listed in the public header files are most likely deprecated Windows 3.1 (or earlier) messages that are retained for compatibility (or because no one at Microsoft decided it was important enough to remove them).

You can find a clue to them in the source to the various Windows replacement projects like Wine or ReactOS. In fact, from the ReactOS headers:

#define WM_SETVISIBLE      0x00000009

This seems to have been the forerunner to the WM_SHOWWINDOW message and is sent simultaneously with the same arguments.

I also found a discussion about message 0x0004 in a newsgroup thread, which even ReactOS don't seem to know about. There the message is described as WM_SIZEWAIT but there's no clue to its function.

In short, these messages are undocumented for a reason - they're not needed or used by any software you might be writing to do, and you should simply ignore them.

Jonathan Potter
  • 36,172
  • 4
  • 64
  • 79
  • Thanks. I was curious because I thought I was receiving that message, but it turns out I wasn't (was missing a `break` statement from the `WM_ACTIVATE` case directly above it). I suspect the unlisted ones will indeed never get received in the message queue. – jmccracken Nov 09 '14 at 02:33