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?

Affirm

do you have the handle for the window that you want it to catch the message? – Tiro

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(). – Braunstein

@David Haim Yes, I will use the handle of the main window to send the message. – Affirm

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 – Tiro

@David Haim But how should I know what integers WinAPI does not use?! – Affirm

for example , here : wiki.winehq.org/List_Of_Windows_Messages – Tiro

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++ – Tiro

@David Haim Is this a good idea? I mean what if a future version of Windows starts using the integer that I choose! – Affirm

Read the friendly manual. – Cooker

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. – Tiro

@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? – Affirm

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 – Tiro

@David Haim I am only using C. I have edited my question to remove the C++ tag. – Affirm

@David Haim What do you mean "it might be", how can we know for sure :-) – Affirm

we can't . this is the mystery of the future :) – Tiro

@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. – Besprent

Answer 1

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.

Delighted

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. – Besprent

@Besprent : 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 – Delighted

Answer 2

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().

Croup

Answer 3

From The New Old Thing by Raymond Chen, December 2, 2003:

Valid window messages break down into four categories.

• 0…0x3FF (WM_USER-1): System-defined messages.

  The meanings of these messages are defined by the operating system and cannot be changed. Do not invent new messages here. Since the meanings are defined by Windows, the operating system understands how to parse the WPARAM and LPARAM parameters and can marshal the messages between processes (or knows to refuse to do so).

• 0x400…0x7FFF (WM_USER…WM_APP-1): Class-defined messages.

  The meanings of these messages is determined by the implementor of the window class. (Informally: By the person who calls RegisterClass for that window class.) For example, the WM_USER+1 message means:

  • TB_ENABLEBUTTON if the window is a toolbar control
  • TTM_ACTIVATE if it is a tooltip control
  • DM_SETDEFID if it is a dialog box.

  If you created your own control, it would mean something else completely different. Since anybody can create a message in this range, the operating system does not know what the parameters mean and cannot perform automatic marshalling.

• 0x8000…0xBFFF (WM_APP…MAXINTATOM-1): Application-defined messages.

  The meanings of these messages is determined by the application that created the window. (Informally: By the person who calls CreateWindow.) This message region was created in Windows 95 to ensure that applications which subclass a window and generate custom messages will not interfere with new messages created by the window class in future versions. Again, since anybody can create a message in this range, the operating system does not know what the parameters mean and cannot perform automatic marshalling.

• 0xC000…0xFFFF (MAXINTATOM…MAXWORD): Registered messages.

  The meanings of these messages is determined by the caller of RegisterWindowMessage. Note that the numerical value of registered messages can change from run to run, so you must use RegisterWindowMessage to obtain the message number. Once again, since anybody can create a message in this range, the operating system does not know what the parameters mean and cannot perform automatic marshalling.

Sydney