Re: Difference between WM_APP and WM_USER

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

On Sat, 3 Jun 2006 07:43:43 -0500, "Jeff Partch [MVP]" <jeffp@xxxxxxxx> wrote:

"Joseph M. Newcomer" <newcomer@xxxxxxxxxxxx> wrote in message
news:rv8282pbr8n4kdpnd3lgr12o6oni0be1f3@xxxxxxxxxx
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.
Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.

Relevant Pages

  • Re: Difference between WM_APP and WM_USER
    ... uses WM_USER-based messages for its own purposes. ... DLL that uses WM_APP+7 as a message to a designated window. ... dll to use this message range. ...
    (microsoft.public.vc.mfc)
  • Re: Threading problem with Garbage Collector
    ... It itself controls calls to a DLL ... "A"), it loads the DLL, which in turn then creates a window (it needs to, ... Disposemethod it uses the label window to synchronize the FreeLibrary ... delegate void DelegateKillDLL(); ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Simulating Control-Alt-Delete?
    ... Winlogon.exe window or not. ... all desktops and all top level windows. ... the WinLogon window didn't show. ... > Write this part of your test suite as a DLL, ...
    (microsoft.public.win32.programmer.kernel)
  • Re: VB6 runtime is supported on Windows 7
    ... The settings window was fairly extensive ... DLL and the settings are organized into a UDT rather ...
    (microsoft.public.vb.general.discussion)
  • Re: window from win32 dll
    ... handle of the DLL, according to the documentation. ... instance of the window to share the one-and-only DC that is a class DC? ... For example, you are presuming RegisterClassEx ... .HINSTANCE storing in dllmain HMODULE ...
    (microsoft.public.vc.mfc)