Using WM_USER, WM_APP or RegisterWindowMessage

Question

Currently, I have a Windows EXE application, with several loaded DLLs. DLLs need to communicate with my windows application through PostMessage and SendMessage.

The Windows EXE application + DLLs are all within a single process.

The message should be private among EXE and DLLs.

I was wondering, should I use

 - WM_USER based message
 - WM_APP based message
 - RegisterWindowMessage

and why?

What happen if there is an external process (another exe), trying to FindWindow of my Windows application, and send the message with same ID?

I wish not to respond, as I am only interested message from DLLs within my own process.

Answer 1

WM_USER messages are typically used to implement control specific messages when developing a control. If you had developed an image editing control, and needed to allow users of the control to set the image, you might go:

#define IECM_SETIMAGE    (WM_USER+1) // image editor control message.

WM_APP messages are typically used to implement application level logic. If you want to send your application a specific message to perform an action...

#define IEAM_SHOWTOOLBAR   (WM_APP+1) // image editor app message

Having both WM_APP and WM_USER ranges seems a little redundant - however there are two use cases where having two ranges is necessary:

• it is possible to create a top level window from a control by simply making it overlapped or popup and giving it a menu and frame. It would then need to both respond as a control, and an application frame window.
• Applications can subclass controls, and then use the WM_APP channel for sending application defined messages to the controls without conflicting with the controls normal WM_USER range of messages.

RegisterWindowMessage is used to create messages when you need a unique message id that is system wide - typically because you want to broadcast the message to windows that are not under your own control, and hence have their own meanings for messages IDs in the WM_APP and WM_USER ranges.