Difference between WM_APP and WM_USER

[n***@yahoo.com]

What is the difference between WM_APP and WM_USER ?
What is for each used?

[Scott McPhillips [MVP]]

Post by n***@yahoo.com
What is the difference between WM_APP and WM_USER ?
What is for each used?

WM_USER is nowadays used by MFC and maybe some newer controls. It used
to be reserved for your use but Microsoft broke the reservation.

WM_APP is reserved for you to use for custom messages within your app.

[AliR]

Range Meaning
0 through WM_USER-1 Messages reserved for use by the system.
WM_USER through 0x7FFF Integer messages for use by private window
classes.
WM_APP through 0xBFFF Messages available for use by applications.
0xC000 through 0xFFFF String messages for use by applications.
Greater than 0xFFFF Reserved by the system.

Message numbers in the first range (0 through WM_USER-1) are defined by the
system. Values in this range that are not explicitly defined are reserved by
the system.

Message numbers in the second range (WM_USER through 0x7FFF) can be defined
and used by an application to send messages within a private window class.
These values cannot be used to define messages that are meaningful
throughout an application, because some predefined window classes already
define values in this range. For example, predefined control classes such as
BUTTON, EDIT, LISTBOX, and COMBOBOX may use these values. Messages in this
range should not be sent to other applications unless the applications have
been designed to exchange messages and to attach the same meaning to the
message numbers.

Message numbers in the third range (0x8000 through 0xBFFF) are available for
application to use as private messages. Message in this range do not
conflict with system messages.

Message numbers in the fourth range (0xC000 through 0xFFFF) are defined at
run time when an application calls the RegisterWindowMessage function to
retrieve a message number for a string. All applications that register the
same string can use the associated message number for exchanging messages.
The actual message number, however, is not a constant and cannot be assumed
to be the same between different sessions.

Message numbers in the fifth range (greater than 0xFFFF) are reserved by the
system.

Post by n***@yahoo.com
What is the difference between WM_APP and WM_USER ?
What is for each used?

[Tom Serface]

The are both just defines, but "these days" we are encouraged to use WM_APP
so that we don't interfere with messages that could be reserved for system
use. WM_APP is just a constant 0x8000.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui/windowsuserinterface/windowing/messagesandmessagequeues/messagesandmessagequeuesreference/messagesandmessagequeuesmessages/wm_app.asp

Tom

Post by n***@yahoo.com
What is the difference between WM_APP and WM_USER ?
What is for each used?

[Doug Harrison [MVP]]

Post by n***@yahoo.com
What is the difference between WM_APP and WM_USER ?
What is for each used?

See:

Which message numbers belong to whom?
http://blogs.msdn.com/oldnewthing/archive/2003/12/02/55914.aspx

See also:

Broadcasting user-defined messages
http://blogs.msdn.com/oldnewthing/archive/2004/05/05/126427.aspx

[Joseph M. Newcomer]

Both are risky to use. WM_USER range messages are used for a lot of purposes by
Microsoft, so it results in all sorts of nasty conflicts if you try to use it for some
other purpose. For example, I had for some years used WM_USER and WM_USER+1 as messages,
which I'd send to child dialogs (I just started numbering them at WM_USER, as suggested by
Petzold). But when I started coding in MFC, I discovered that MFC uses WM_USER and
WM_USER+1 as internal messages to CDialog classes. Oops (that problem took many hours to
discover). Sometimes you want to "broadcast" a message to child windows using
SendMessageToDescendants, and you can't be sure when you're going to hit some control that
uses WM_USER-based messages for its own purposes.

Now you can use WM_APP, but this has a serious "modularity" problem. Suppose you write a
DLL that uses WM_APP+7 as a message to a designated window. Suppose I write a DLL that
uses WM_APP+7 as a message to a designated window. Now suppose some poor programmer wants
to use both of our DLLs in an application, both called from the same window which needs a
target. The problem is that this programmer doesn't see WM_APP+7 as the value; what the
programmer sees is "UWM_MY_NOTIFICATION" and "UWM_YOUR_DATA_READY" as messages. Big
whoops. (No, don't say it won't happen or can't happen. It has. It's happened to me
several times). This is why I gave up entirely some years ago and use only Registered
Window Messages with a GUID in the name. It is the Only Safe Way To Avoid Future
Disaster.

See my essay on Message Management on my MVP Tips site.
joe

Post by n***@yahoo.com
What is the difference between WM_APP and WM_USER ?
What is for each used?

Joseph M. Newcomer [MVP]
email: ***@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

[Jeff Partch [MVP]]

Post by Joseph M. Newcomer
Both are risky to use. WM_USER range messages are used for a lot of purposes by
Microsoft, so it results in all sorts of nasty conflicts if you try to use it for some
other purpose. For example, I had for some years used WM_USER and WM_USER+1 as messages,
which I'd send to child dialogs (I just started numbering them at WM_USER, as suggested by
Petzold). But when I started coding in MFC, I discovered that MFC uses WM_USER and
WM_USER+1 as internal messages to CDialog classes. Oops (that problem took many hours to
discover). Sometimes you want to "broadcast" a message to child windows using
SendMessageToDescendants, and you can't be sure when you're going to hit some control that
uses WM_USER-based messages for its own purposes.

WM_USER and WM_USER+1 are the dialog WNDCLASS messages DM_GETDEFID and
DM_SETFDEFID respectively. These are not MFC messages. They have been
defined in Windows.h since version 2.x according to my copy of the WIN3.1
SDK Vol 3: Messages, Structures and Macros from 1992. This book also
describes messages in the WM_USER range as being reserved "for use by
private window classes". That is unique only to the WNDCLASS implementation.
I reckon it was never appropriate to co-opt a private internal message for
external use with a WNDCLASS you didn't call RegisterClass for. And
broadcasting or even 'broadcasting' such a message is outrageously
irresponsible.

Post by Joseph M. Newcomer
Now you can use WM_APP, but this has a serious "modularity" problem.
Suppose you write a
DLL that uses WM_APP+7 as a message to a designated window. Suppose I write a DLL that
uses WM_APP+7 as a message to a designated window. Now suppose some poor programmer wants
to use both of our DLLs in an application, both called from the same window which needs a
target. The problem is that this programmer doesn't see WM_APP+7 as the value; what the
programmer sees is "UWM_MY_NOTIFICATION" and "UWM_YOUR_DATA_READY" as messages. Big

The WM_APP range has always been either reserverd for future use -- before
there was a WM_APP, or reserved for use by an application for its internal
use. Because a dll is not an application it has never been appropriate for a
dll to use this message range. And again, broadcasting such a message is
outrageously irresponsible.

Post by Joseph M. Newcomer
whoops. (No, don't say it won't happen or can't happen. It has. It's happened to me
several times). This is why I gave up entirely some years ago and use only Registered
Window Messages with a GUID in the name. It is the Only Safe Way To Avoid Future
Disaster.

I agree. These messages ranges have been thoughtlessly or misguidedly (darn
you Charles Petzold and Paul DiLascia) misused by too many people for far to
long to ever rely on them for their intended purposes. But I argue that the
intent was never unclear from even a cursory reading of the documentation.

[Joseph M. Newcomer]

Then I think it may have been because I was using those messages and they got accidentally
sent to a dialog. Since I stopped using the messages, I stopped worrying about the issue
(this hit me back in 1995 or so. MFC had SendMessageToDescendants, which is probably what
I was using). But the moral is the same: avoid these messages.

The key was that I would "broadcast" a user-defined message downward from my mainframe;
this was a way of getting messages to specific views or, ultimately, documents, where I
didn't have to know or care what I was sending to. The recipient would handle it, and I
wouldn't care.

I was using "broadcast" in the top-down-tree sense, not in the HWND_BROADCAST sense.
joe

Post by Jeff Partch [MVP]

Post by Joseph M. Newcomer
Both are risky to use. WM_USER range messages are used for a lot of purposes by
Microsoft, so it results in all sorts of nasty conflicts if you try to use it for some
other purpose. For example, I had for some years used WM_USER and WM_USER+1 as messages,
which I'd send to child dialogs (I just started numbering them at WM_USER,
as suggested by
Petzold). But when I started coding in MFC, I discovered that MFC uses WM_USER and
WM_USER+1 as internal messages to CDialog classes. Oops (that problem took many hours to
discover). Sometimes you want to "broadcast" a message to child windows using
SendMessageToDescendants, and you can't be sure when you're going to hit
some control that
uses WM_USER-based messages for its own purposes.

WM_USER and WM_USER+1 are the dialog WNDCLASS messages DM_GETDEFID and
DM_SETFDEFID respectively. These are not MFC messages. They have been
defined in Windows.h since version 2.x according to my copy of the WIN3.1
SDK Vol 3: Messages, Structures and Macros from 1992. This book also
describes messages in the WM_USER range as being reserved "for use by
private window classes". That is unique only to the WNDCLASS implementation.
I reckon it was never appropriate to co-opt a private internal message for
external use with a WNDCLASS you didn't call RegisterClass for. And
broadcasting or even 'broadcasting' such a message is outrageously
irresponsible.

Post by Joseph M. Newcomer
Now you can use WM_APP, but this has a serious "modularity" problem.
Suppose you write a
DLL that uses WM_APP+7 as a message to a designated window. Suppose I write a DLL that
uses WM_APP+7 as a message to a designated window. Now suppose some poor
programmer wants
to use both of our DLLs in an application, both called from the same window which needs a
target. The problem is that this programmer doesn't see WM_APP+7 as the value; what the
programmer sees is "UWM_MY_NOTIFICATION" and "UWM_YOUR_DATA_READY" as messages. Big

The WM_APP range has always been either reserverd for future use -- before
there was a WM_APP, or reserved for use by an application for its internal
use. Because a dll is not an application it has never been appropriate for a
dll to use this message range. And again, broadcasting such a message is
outrageously irresponsible.

Post by Joseph M. Newcomer
whoops. (No, don't say it won't happen or can't happen. It has. It's happened to me
several times). This is why I gave up entirely some years ago and use only Registered
Window Messages with a GUID in the name. It is the Only Safe Way To Avoid Future
Disaster.

I agree. These messages ranges have been thoughtlessly or misguidedly (darn
you Charles Petzold and Paul DiLascia) misused by too many people for far to
long to ever rely on them for their intended purposes. But I argue that the
intent was never unclear from even a cursory reading of the documentation.

Joseph M. Newcomer [MVP]
email: ***@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

[Tom Serface]

Hi Jeff,

I use these, but I always send my APP messages to a specific window in my
application. I agree that doing this from a DLL may be problematic. I have
seen libraries have user defined messages and mostly they just say in the
documentation that they are doing it and/or only send the messages to their
own windows which would be safe as well (or at least more safe).

Tom

Post by Jeff Partch [MVP]
The WM_APP range has always been either reserverd for future use -- before
there was a WM_APP, or reserved for use by an application for its internal
use. Because a dll is not an application it has never been appropriate for
a dll to use this message range. And again, broadcasting such a message is
outrageously irresponsible.

[Jeff Partch [MVP]]

Post by Tom Serface
Hi Jeff,
I use these, but I always send my APP messages to a specific window in my
application. I agree that doing this from a DLL may be problematic. I
have seen libraries have user defined messages and mostly they just say in
the documentation that they are doing it and/or only send the messages to
their own windows which would be safe as well (or at least more safe).

Thanks. Tom. Of course I'm not the Voice Of Truth. Sorry if I came across as
though my pronouncements were the Last Word on the subject.