WM_APP vs WM_USER
-
I'm having a discussion with Masoud Samimi about user-defined messages. In Programming Windows with MFC 2nd Ed. by Jeff Prosise, Jeff states on page 431:
WM_USER, which is defined as 0x400 in the header file Winuser.h, specifies the low end of a range of message IDs an application can use without conflicting with the message IDs of standard Windows messages such as WM_CREATE and WM_PAINT. An application is free to use message IDs from WM_USER's 0x400 through 0x7FFF for its own purposes. Messages in this range are referred to as user-defined messages. Because dialog boxes use some message IDs in this range themselves, DlgDemo2 arbitrarily adds 0x100 to WM_USER to avoid conflicts.
I grew up with the idea that WM_USER + n messages should be avoided becuase MFC uses message numbers close to this range, and you are never sure when MS will add new MFC messages, possibly above the WM_USER+0x100 limit. Instead, users should use values above WM_APP, or better still, use ::RegisterMessage() to ensure a unique value. What's the current thinking on this? cheers, Chris Maunde
-
I'm having a discussion with Masoud Samimi about user-defined messages. In Programming Windows with MFC 2nd Ed. by Jeff Prosise, Jeff states on page 431:
WM_USER, which is defined as 0x400 in the header file Winuser.h, specifies the low end of a range of message IDs an application can use without conflicting with the message IDs of standard Windows messages such as WM_CREATE and WM_PAINT. An application is free to use message IDs from WM_USER's 0x400 through 0x7FFF for its own purposes. Messages in this range are referred to as user-defined messages. Because dialog boxes use some message IDs in this range themselves, DlgDemo2 arbitrarily adds 0x100 to WM_USER to avoid conflicts.
I grew up with the idea that WM_USER + n messages should be avoided becuase MFC uses message numbers close to this range, and you are never sure when MS will add new MFC messages, possibly above the WM_USER+0x100 limit. Instead, users should use values above WM_APP, or better still, use ::RegisterMessage() to ensure a unique value. What's the current thinking on this? cheers, Chris Maunde
I'm think you're sure. I normally use WM_APP because the SDK docs say: ---- SDK docs quote start ---- Only use RegisterWindowMessage when more than one application must process the same message. For sending private messages within a window class, an application can use any integer in the range WM_USER through 0x7FFF. (Messages in this range are private to a window class, not to an application. For example, predefined control classes such as BUTTON, EDIT, LISTBOX, and COMBOBOX may use values in this range.) ---- SDK docs quote end ---- Use RegisterWindowMessage with a GUID would be the most relialble solution I think but I would like to know why the sdk docs says use AM_APP for private message used only by one app.
-
I'm having a discussion with Masoud Samimi about user-defined messages. In Programming Windows with MFC 2nd Ed. by Jeff Prosise, Jeff states on page 431:
WM_USER, which is defined as 0x400 in the header file Winuser.h, specifies the low end of a range of message IDs an application can use without conflicting with the message IDs of standard Windows messages such as WM_CREATE and WM_PAINT. An application is free to use message IDs from WM_USER's 0x400 through 0x7FFF for its own purposes. Messages in this range are referred to as user-defined messages. Because dialog boxes use some message IDs in this range themselves, DlgDemo2 arbitrarily adds 0x100 to WM_USER to avoid conflicts.
I grew up with the idea that WM_USER + n messages should be avoided becuase MFC uses message numbers close to this range, and you are never sure when MS will add new MFC messages, possibly above the WM_USER+0x100 limit. Instead, users should use values above WM_APP, or better still, use ::RegisterMessage() to ensure a unique value. What's the current thinking on this? cheers, Chris Maunde
I always use WM_APP, since many (most?) of the common control messages are defined as WM_USER+n, and using WM_APP for my own messages avoids any collisions
-
I'm having a discussion with Masoud Samimi about user-defined messages. In Programming Windows with MFC 2nd Ed. by Jeff Prosise, Jeff states on page 431:
WM_USER, which is defined as 0x400 in the header file Winuser.h, specifies the low end of a range of message IDs an application can use without conflicting with the message IDs of standard Windows messages such as WM_CREATE and WM_PAINT. An application is free to use message IDs from WM_USER's 0x400 through 0x7FFF for its own purposes. Messages in this range are referred to as user-defined messages. Because dialog boxes use some message IDs in this range themselves, DlgDemo2 arbitrarily adds 0x100 to WM_USER to avoid conflicts.
I grew up with the idea that WM_USER + n messages should be avoided becuase MFC uses message numbers close to this range, and you are never sure when MS will add new MFC messages, possibly above the WM_USER+0x100 limit. Instead, users should use values above WM_APP, or better still, use ::RegisterMessage() to ensure a unique value. What's the current thinking on this? cheers, Chris Maunde
I really liked Joseph M. Newcomer's article "Message Management" and since then I have been using registered messages. It's only slightly more work but it seems to give me a little more assurance than WM_APP+ or WM_USER+ I have to admit that I have not, in recent memory, experienced any sort of message collision/confusion with WM_APP+ but I don't really use than many user-defined messages in my apps. Mr. Mewcomer seemed to have some solid reasons to his methods and I can't think of a good reason not to follow his lead :) so that's my answer. Does anyone know if there is a limit to the number of UDM's you can register? Byro
-
I'm having a discussion with Masoud Samimi about user-defined messages. In Programming Windows with MFC 2nd Ed. by Jeff Prosise, Jeff states on page 431:
WM_USER, which is defined as 0x400 in the header file Winuser.h, specifies the low end of a range of message IDs an application can use without conflicting with the message IDs of standard Windows messages such as WM_CREATE and WM_PAINT. An application is free to use message IDs from WM_USER's 0x400 through 0x7FFF for its own purposes. Messages in this range are referred to as user-defined messages. Because dialog boxes use some message IDs in this range themselves, DlgDemo2 arbitrarily adds 0x100 to WM_USER to avoid conflicts.
I grew up with the idea that WM_USER + n messages should be avoided becuase MFC uses message numbers close to this range, and you are never sure when MS will add new MFC messages, possibly above the WM_USER+0x100 limit. Instead, users should use values above WM_APP, or better still, use ::RegisterMessage() to ensure a unique value. What's the current thinking on this? cheers, Chris Maunde