Registered Messages vs. WM_USER

When sending messages and notification from user-created controls, one has two options to define custom messages. The first is to send a WM_USER message. That is, take the WM_USER constant and add to it a number. For example:

#define SPECIAL_CTRL_CHANGE(WM_USER + 1000)
This allows any window to capture the message or notification using normal ON_COMMAND/ON_NOTIFY macros. However, using WM_USER for normal messages is a mistake. Suppose I created a component called "Special" and another programmer from another side of the galaxy creates a component called "VerySpecial". Both of us could have several messages sent and both would use WM_USER messages. If by any chance both controls will use the same message, a windows program might behave in an unexpected way, since both use the exact same message. This problem exists only when using the ON_COMMAND macro and not ON_NOTIFY, since ON_NOTIFY uses the control id and not just the message code.

Therefore the conclusion is to use WM_USER messages only when sending notification messages and not normal windows messages.

One alternative to using custom Windows messages that are based on the WM_USER message is to register your own Windows messages. The idea behind registered messages is to create a unique Windows message based upon a string. Any window that knows the string can obtain the message code and therefore, respond to the predefined message. This allows several components to create custom messages, and by simply concatenating the component name to the message name, they can be sure that their string is unique, and therefore the message code is unique.

Here's an example of how to add the message handler of a registered message on the client side using the MFC message map.

static const UINT MsgSpecialCtrlChange = ::RegisterWindowMessage(SPECIAL_CTRL_CHANGE);

BEGIN_MESSAGE_MAP(... //{{AFX_MSG_MAP(... . . //}}AFX_MSG_MAP ON_REGISTERED_MESSAGE(MsgSpecialCtrlChange, OnSpecialCtrlChange) END_MESSAGE_MAP()

Where SPECIAL_CTRL_CHANGE is:

#define SPECIAL_CTRL_CHANGE _T("Special_Change")
Another nice advantage that registered message can provide, is the ability to capture the message sent from another application, again by only knowing the string.

The Windows Common Controls use this type of message routing from the DLL to the user application for several messages such as FindOrReplace command in RichEdit control. The intellimouse messages are also sent with registered messages, instead of creating new windows messages for them.

Date Last Updated: March 5, 1999



Comments

  • WM_USER & ON_COMMAND ?

    Posted by Legacy on 07/24/2001 12:00am

    Originally posted by: zgabeata iftode

    Although I agree that there are obvious benefits to registered messages, I still don't get it: how do you use WM_USER messages with the ON_COMMAND macro? Or with ON_NOTIFY?

    As far as I know ON_COMMAND is limited to WM_COMMAND message and ON_NOTIFY is limited to WM_NOTIFY message. Can you post a piece of code that uses ON_COMMAND to catch any WM_USER message? Oh, and before you do that, make sure it actually works!

    Reply
  • There is an excellent article on this...

    Posted by Legacy on 07/09/2001 12:00am

    Originally posted by: Breckin Loggins

    Joseph M. Newcomer has a most excellent article clearly describing when it is appropriate to use WM_APP and when to use registered messages. He also clearly explains why using WM_USER is a Bad Idea. I'm listening to him now. I was using WM_USER and my app worked fine on W2K but when I tried it on W98 some of my messages weren't working. Turns out it's because W98 has some controls installed that trampled over the WM_USER message space, so I changed them to WM_APP and haven't had a problem since. Note that in this case I'm not using registered messages because I'm not sending the messages across processes.

    Here's the link:

    http://www.pgh.net/~newcomer/messages.htm

    Reply
  • do they work across dlls?

    Posted by Legacy on 03/14/1999 12:00am

    Originally posted by: selom ofori

    I recently took parts of my application out and put them in an mfc extension dll. The registered messages didn't seem to work anymore. The values I was getting was totally wacked and all my switch statements wouldn't work. I eventually had to switch them to hard-coded numbers. Was I doing something wrong or do they just not work across dlls?

    Reply
  • Performance of registered messages

    Posted by Legacy on 03/10/1999 12:00am

    Originally posted by: Stefan Niermann

    I think, WM_USER + xxxx must be somewhat faster than registered messages. Every time you send a registered message, Windows looks for the registration of it. The message will not be dispatched to the window if the OS doesn't find that registration. I realized that, when I tried to send a message with a constant code in the range of registered messages.

    Reply
  • WM_USER or WM_APP is ok for interprocess messages

    Posted by Legacy on 03/05/1999 12:00am

    Originally posted by: BadDog

    If all you're doing is defining a message to be sent to another window in the same application, then using
    WM_USER or WM_APP messages is not a problem.
    
    

    ...for interprocess communication: Use WM_USER/WM_APP
    ...for broadcasting messages: Use RegisterWindowMessage
    ...for communicating with another application: depends...if you want to grab a specific application and send messages to it, then setting up something like a semaphore or finding a specific window class and then sending it messages instead of broadcasting messages to the whole system seems like it would be better.

    Most of the time when I've started down the path of using a registered message, I've come to the realization that it is more than I need.

    Reply
Leave a Comment
  • Your email address will not be published. All fields are required.

Top White Papers and Webcasts

  • Live Event Date: September 10, 2014 @ 11:00 a.m. ET / 8:00 a.m. PT Modern mobile applications connect systems-of-engagement (mobile apps) with systems-of-record (traditional IT) to deliver new and innovative business value. But the lifecycle for development of mobile apps is also new and different. Emerging trends in mobile development call for faster delivery of incremental features, coupled with feedback from the users of the app "in the wild". This loop of continuous delivery and continuous feedback is …

  • Java developers know that testing code changes can be a huge pain, and waiting for an application to redeploy after a code fix can take an eternity. Wouldn't it be great if you could see your code changes immediately, fine-tune, debug, explore and deploy code without waiting for ages? In this white paper, find out how that's possible with a Java plugin that drastically changes the way you develop, test and run Java applications. Discover the advantages of this plugin, and the changes you can expect to see …

Most Popular Programming Stories

More for Developers

Latest Developer Headlines

RSS Feeds