Re: Difference between WM_APP and WM_USER
"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message
news:rv8282pbr8n4kdpnd3lgr12o6oni0be1f3@4ax.com...
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.
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.
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.
--
Jeff Partch [VC++ MVP]