WM_USER vs WM_APP

Question

I want the worker threads to send a user-defined message to the UI thread message queue, but I am not sure if I should use WM_USER or WM_APP. The documentation for WM_APP says:

WM_APP through 0xBFFF

Messages available for use by applications.

So should I use WM_APP?

do you have the handle for the window that you want it to catch the message? — David Haim, Jun 15 '15 at 11:03
WM_APP is the safer choice, it is unlikely to conflict with messages used by controls. Which does assume you'd know what other background threads are poking the UI thread. If you want it really safe and have the guarantee there is never a conflict then you'd use RegisterWindowMessage(). — Hans Passant, Jun 15 '15 at 11:05
@David Haim Yes, I will use the handle of the main window to send the message. — Tom, Jun 15 '15 at 11:06
than you can just choose an integer WinApi doesn't alredy use it and send it , plus writing a case for it in the callback function that the window is registered on — David Haim, Jun 15 '15 at 11:07
@David Haim But how should I know what integers WinAPI does not use?! — Tom, Jun 15 '15 at 11:08
for example , here : http://wiki.winehq.org/List_Of_Windows_Messages — David Haim, Jun 15 '15 at 11:09
plus, you might want some more modern-OOP-C++11 way of doing it instead of WinApi way, think how you might do it with regular standard-C++ — David Haim, Jun 15 '15 at 11:11
@David Haim Is this a good idea? I mean what if a future version of Windows starts using the integer that I choose! — Tom, Jun 15 '15 at 11:11
[Read the friendly manual](https://msdn.microsoft.com/en-us/library/windows/desktop/ms644931%28v=vs.85%29.aspx). — Lundin, Jun 15 '15 at 11:13
that is why doing it in regular C++ way is maybe a better idea. although I really dough Microsoft will do any future change in WinApi or in native -windows code in general. it seems like they move on developing new stuff for .Net and WinRt. it is highly unlikely that WinApi will change. — David Haim, Jun 15 '15 at 11:13
@David Haim But isn't the point of `WM_APP through 0xBFFF` is to guarantee that messages in this range will never be used by Windows and so I can use them in my application? — Tom, Jun 15 '15 at 11:19
it might be , that is why I commented this question and not put an answer. I will advise you again to turn into regular C++ instead of WinApi — David Haim, Jun 15 '15 at 11:22
@David Haim I am only using `C`. I have edited my question to remove the `C++` tag. — Tom, Jun 15 '15 at 11:25
@David Haim What do you mean *"it might be"*, how can we know for sure :-) — Tom, Jun 15 '15 at 11:26
@DavidHaim: Windows RT is the **native** successor to the Windows API. Your remaining comments are pretty much misleading, and fail to even remotely address the question being asked. Future readers can safely skip over them. — IInspectable, Jun 15 '15 at 12:37

score 11 · Answer 1 · edited Jun 20 '20 at 09:12

Microsoft is really conservative on its APIs, so you can be confident when you see that messages WM_APP through 0xBFFF do not conflict with system messages. It would need a major change in Windows API for that rule to be broken, and many other applications would not survive.

The only relevant question is : do you need to use messages in the WM_USER range or in the WM_APP range?

MSDN says:

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 applications to use as private messages. Messages in this range do not conflict with system messages.

(emphasis mine)

If you explicitly post those messages to a window that is designed to handle them in a specific way and is not a subclass of a Windows control, you can use WM_USER range. If they are to be handled directly by the message loop (like WM_QUIT for example), or if in doubt, use the WP_APP range.

Said differently, as you do not need a lot of such messages and as you want to post them to the UI thread message queue, simply use one in the WM_APP range that is not already used by your application, and be sure to document it for later maintenance.

Messages posted to a window are in general not handled by a message loop. The message loop dispatches them to the appropriate recipient for handling. `WM_QUIT` is different in that it is a message that is posted to a **thread**, not a **window**. — IInspectable, Jun 15 '15 at 12:33
@IInspectable : OP said the message was to be posted to *the UI thread message queue*. Ok, I've just seen that OP said in its comment that it would be handled by its main window, so WM_USER should be safe ... provided its main window is not subclassed from a dialog window. That's why my advice is *if in doubt* use WM_APP range — Serge Ballesta, Jun 15 '15 at 13:03

score 3 · Answer 2 · answered Jun 15 '15 at 12:28

If you completely control the window class of the destination window (i.e. you defined it, you're not subclassing/superclassing another class, and you don't use IsDialogMessage on your window) then you can use WM_USER+xxx (with x >= 0).

Otherwise, you should use at least WM_APP+xxx, provided you control the application that contains the window.

Failing that, the only option left would be RegisterWindowMessage().

WM_USER vs WM_APP

2 Answers2

Linked