When passing a value to a function that takes both a WPARAM and a LPARAM parameter, does it matter on which of them I pass it? Someone told me that if I use Windows x64 I should use WPARAM; is this true?
Jonathan Leffler584k9696 gold badges705705 silver badges10551055 bronze badges
AdrianAdrian6,9462525 gold badges8484 silver badges161161 bronze badges
5 Answers
When sending messages,
WPARAM
and LPARAM
parameters have specific interpretations depending on the message. You need to pass those parameters in the way that the message that you are sending expects them to be passed. If you are defining your own message (perhaps via an offset from WM_USER
, WM_APP
, or RegisterWindowMessage
), then you obviously have a bit more latitude.In the days of 16-bit Windows, a
WPARAM
was a 16-bit word, while LPARAM
was a 32-bit long. These distinctions went away in Win32; they both became 32-bit values.According to this,
Aaron KlotzAaron KlotzLPARAM
is defined as LONG_PTR
, which in 64-bit Windows is a signed, 64-bit value. WPARAM
is defined as UINT_PTR
, which in 64-bit Windows is an unsigned, 64-bit value. If you are defining your own message, you might want to assign its parameters accordingly.8,25211 gold badge2121 silver badges2222 bronze badges
The history of its definition has changed over the years.
WINDOWS.H (Windows 2.03 SDK, c. 1988)
WinDefs.h (c. 1999)
WinDef.h (c. 2005)
Bonus Reading
- What do the letters W and L stand for in WPARAM and LPARAM?(
W
is for unsigned 16-bitWORD
, andL
is for signed 32-bitLONG
) - What happens to WPARAM, LPARAM, and LRESULT when they travel between 32-bit and 64-bit windows?(the unsigned is zero-extended, the signed is sign-extended)
126k198198 gold badges705705 silver badges10231023 bronze badges
It's message-specific. You can use this list of system-defined message categories as reference. Select a group, then a message from the group to see what the message specifies you should pass as WPARAM/LPARAM.
Raymond Chen explains why we have two params.
lunixbochsLresult
lunixbochs15.6k22 gold badges3030 silver badges4040 bronze badges
Yes, the order matters.
WPARAM
sent/posted in one side winds up WPARAM
on the other end; likewise for LPARAM
.If you have your own custom messages you can use
Jonathan LefflerWPARAM
and LPARAM
for anything you want. (There may be some common conventions though.) 584k9696 gold badges705705 silver badges10551055 bronze badges
seandseand
Yes, it does. I once passed them in swapped order and the function I call fails. Nevertheless, you should consult MSDN when in doubt. I never program in Win64 though, so I don't whether there are differences between Win32 and Win64 regarding
hackjutsuWPARAM
/LPARAM
behavior.3,06388 gold badges3030 silver badges6161 bronze badges
LeleDumboLeleDumbo8,24144 gold badges1919 silver badges3434 bronze badges
Not the answer you're looking for? Browse other questions tagged c++apiwinapi or ask your own question.
-->Sends the specified message to a window or windows. The SendMessage function calls the window procedure for the specified window and does not return until the window procedure has processed the message.
To send a message and return immediately, use the SendMessageCallback or SendNotifyMessage function. To post a message to a thread's message queue and return immediately, use the PostMessage or PostThreadMessage function.
Syntax
Parameters
hWnd
Type: HWND
A handle to the window whose window procedure will receive the message. If this parameter is HWND_BROADCAST ((HWND)0xffff), the message is sent to all top-level windows in the system, including disabled or invisible unowned windows, overlapped windows, and pop-up windows; but the message is not sent to child windows.
Message sending is subject to UIPI. The thread of a process can send messages only to message queues of threads in processes of lesser or equal integrity level.
Msg
Type: UINT
The message to be sent.
For lists of the system-provided messages, see System-Defined Messages.
wParam
Snap on speaker bar. Type: WPARAM
Additional message-specific information.
lParam
Type: LPARAM
Additional message-specific information.
Return Value
Type: Type: LRESULT
Upgrade Error Wparam 100 Lparam 1002 2
The return value specifies the result of the message processing; it depends on the message sent.
Remarks
When a message is blocked by UIPI the last error, retrieved with GetLastError, is set to 5 (access denied).
Applications that need to communicate using HWND_BROADCAST should use the RegisterWindowMessage function to obtain a unique message for inter-application communication.
The system only does marshalling for system messages (those in the range 0 to (WM_USER-1)). To send other messages (those >= WM_USER) to another process, you must do custom marshalling.
If the specified window was created by the calling thread, the window procedure is called immediately as a subroutine. If the specified window was created by a different thread, the system switches to that thread and calls the appropriate window procedure. Messages sent between threads are processed only when the receiving thread executes message retrieval code. The sending thread is blocked until the receiving thread processes the message. However, the sending thread will process incoming nonqueued messages while waiting for its message to be processed. To prevent this, use SendMessageTimeout with SMTO_BLOCK set. For more information on nonqueued messages, see Nonqueued Messages.
An accessibility application can use SendMessage to send WM_APPCOMMAND messages to the shell to launch applications. This functionality is not guaranteed to work for other types of applications.
Examples
For an example, see Displaying Keyboard Input.
Requirements
Minimum supported client | Windows 2000 Professional [desktop apps only] |
Minimum supported server | Windows 2000 Server [desktop apps only] |
Target Platform | Windows |
Header | winuser.h (include Windows.h) |
Library | User32.lib |
DLL | User32.dll |
See Also
Conceptual
Reference
-->Sends the specified message to a window or windows. If the window was created by the calling thread, SendNotifyMessage calls the window procedure for the window and does not return until the window procedure has processed the message. If the window was created by a different thread, SendNotifyMessage passes the message to the window procedure and returns immediately; it does not wait for the window procedure to finish processing the message.
Syntax
Parameters
hWnd
Type: HWND
A handle to the window whose window procedure will receive the message. If this parameter is HWND_BROADCAST ((HWND)0xffff), the message is sent to all top-level windows in the system, including disabled or invisible unowned windows, overlapped windows, and pop-up windows; but the message is not sent to child windows.
Msg
Type: UINT
The message to be sent.
For lists of the system-provided messages, see System-Defined Messages.
wParam
Type: WPARAM
Additional message-specific information.
lParam
Type: LPARAM
Additional message-specific information.
Return Value
Type: Type: BOOL
If the function succeeds, the return value is nonzero.
If the function fails, the return value is zero. To get extended error information, call GetLastError.
Remarks
If you send a message in the range below WM_USER to the asynchronous message functions (PostMessage, SendNotifyMessage, and SendMessageCallback), its message parameters cannot include pointers. Otherwise, the operation will fail. The functions will return before the receiving thread has had a chance to process the message and the sender will free the memory before it is used.
Applications that need to communicate using HWND_BROADCAST should use the RegisterWindowMessage function to obtain a unique message for inter-application communication.
The system only does marshalling for system messages (those in the range 0 to (WM_USER-1)). To send other messages (those >= WM_USER) to another process, you must do custom marshalling.
Requirements
Minimum supported client | Windows 2000 Professional [desktop apps only] |
Minimum supported server | Windows 2000 Server [desktop apps only] |
Target Platform | Windows |
Header | winuser.h (include Windows.h) |
Library | User32.lib |
DLL | User32.dll |
See Also
Conceptual
Reference
-->This note describes the MFC message map facility.
The Problem
Microsoft Windows implements virtual functions in window classes that use its messaging facility. Due to the large number of messages involved, providing a separate virtual function for each Windows message would create a prohibitively large vtable.
Because the number of system-defined Windows messages changes over time, and because applications can define their own Windows messages, message maps provide a level of indirection that prevents interface changes from breaking existing code.
Overview
MFC provides an alternative to the switch statement that was used in traditional Windows-based programs to handle messages sent to a window. A mapping from messages to methods can be defined so that when a message is received by a window, the appropriate method is called automatically. This message-map facility is designed to resemble virtual functions but has additional benefits not possible with C++ virtual functions.
Defining a Message Map
The DECLARE_MESSAGE_MAP macro declares three members for a class.
- A private array of AFX_MSGMAP_ENTRY entries called _messageEntries.
- A protected AFX_MSGMAP structure called messageMap that points to the _messageEntries array.
- A protected virtual function called
GetMessageMap
that returns the address of messageMap.
This macro should be put in the declaration of any class using message maps. By convention, it is at the end of the class declaration. For example:
This is the format generated by AppWizard and ClassWizard when they create new classes. The //{{ and //}} brackets are needed for ClassWizard.
The message map's table is defined by using a set of macros that expand to message map entries. A table starts with a BEGIN_MESSAGE_MAP macro call, which defines the class that is handled by this message map and the parent class to which unhandled messages are passed. The table ends with the END_MESSAGE_MAP macro call.
Between these two macro calls is an entry for each message to be handled by this message map. Every standard Windows message has a macro of the form ON_WM_MESSAGE_NAME that generates an entry for that message.
A standard function signature has been defined for unpacking the parameters of each Windows message and providing type safety. These signatures may be found in the file Afxwin.h in the declaration of CWnd. Each one is marked with the keyword afx_msg for easy identification.
Note
ClassWizard requires that you use the afx_msg keyword in your message map handler declarations.
These function signatures were derived by using a simple convention. The name of the function always starts with
'On
'. This is followed by the name of the Windows message with the 'WM_' removed and the first letter of each word capitalized. The ordering of the parameters is wParam followed by LOWORD
(lParam) then HIWORD
(lParam). Unused parameters are not passed. Any handles that are wrapped by MFC classes are converted to pointers to the appropriate MFC objects. The following example shows how to handle the WM_PAINT message and cause the CMyWnd::OnPaint
function to be called:The message map table must be defined outside the scope of any function or class definition. It should not be put in an extern 'C' block.
Note
ClassWizard will modify the message map entries that occur between the //{{ and //}} comment bracket.
User Defined Windows Messages
User-defined messages may be included in a message map by using the ON_MESSAGE macro. This macro accepts a message number and a method of the form:
In this example, we establish a handler for a custom message that has a Windows message ID derived from the standard WM_USER base for user-defined messages. The following example shows how to call this handler:
The range of user-defined messages that use this approach must be in the range WM_USER to 0x7fff.
Note
ClassWizard does not support entering ON_MESSAGE handler routines from the ClassWizard user interface. You must manually enter them from the Visual C++ editor. ClassWizard will parse these entries and let you browse them just like any other message-map entries.
Registered Windows Messages
The RegisterWindowMessage function is used to define a new window message that is guaranteed to be unique throughout the system. The macro ON_REGISTERED_MESSAGE is used to handle these messages. This macro accepts a name of a UINT NEAR variable that contains the registered windows message ID. For example
The registered Windows message ID variable (WM_FIND in this example) must be a NEAR variable because of the way ON_REGISTERED_MESSAGE is implemented.
The range of user-defined messages that use this approach will be in the range 0xC000 to 0xFFFF.
Note
ClassWizard does not support entering ON_REGISTERED_MESSAGE handler routines from the ClassWizard user interface. You must manually enter them from the text editor. ClassWizard will parse these entries and let you browse them just like any other message-map entries.
Command Messages
Command messages from menus and accelerators are handled in message maps with the ON_COMMAND macro. This macro accepts a command ID and a method. Only the specific WM_COMMAND message that has a wParam equal to the specified command ID is handled by the method specified in the message-map entry. Command handler member functions take no parameters and return void. The macro has the following form:
Command update messages are routed through the same mechanism, but use the ON_UPDATE_COMMAND_UI macro instead. Command update handler member functions take a single parameter, a pointer to a CCmdUI object, and return void. The macro has the form
Advanced users can use the ON_COMMAND_EX macro, which is an extended form of command message handlers. The macro provides a superset of the ON_COMMAND functionality. Extended command-handler member functions take a single parameter, a UINT that contains the command ID, and return a BOOL. The return value should be TRUE to indicate that the command has been handled. Otherwise routing will continue to other command target objects.
Examples of these forms:
- Inside Resource.h (usually generated by Visual C++)
- Inside the class declaration
- Inside the message map definition
- In the implementation file
Advanced users can handle a range of commands by using a single command handler: ON_COMMAND_RANGE or ON_COMMAND_RANGE_EX. See the product documentation for more information about these macros.
Note
ClassWizard supports creating ON_COMMAND and ON_UPDATE_COMMAND_UI handlers, but it does not support creating ON_COMMAND_EX or ON_COMMAND_RANGE handlers. However, Class Wizard will parse and let you browse all four command handler variants.
Control Notification Messages
Messages that are sent from child controls to a window have an extra bit of information in their message map entry: the control's ID. The message handler specified in a message map entry is called only if the following conditions are true:
- The control notification code (high word of lParam), such as BN_CLICKED, matches the notification code specified in the message-map entry.
- The control ID (wParam) matches the control ID specified in the message-map entry.
Custom control notification messages may use the ON_CONTROL macro to define a message map entry with a custom notification code. This macro has the form
For advanced usage ON_CONTROL_RANGE can be used to handle a specific control notification from a range of controls with the same handler.
Note
ClassWizard does not support creating an ON_CONTROL or ON_CONTROL_RANGE handler in the user interface. You must manually enter them with the text editor. ClassWizard will parse these entries and let you browse them just like any other message map entries.
The Windows Common Controls use the more powerful WM_NOTIFY for complex control notifications. This version of MFC has direct support for this new message by using the ON_NOTIFY and ON_NOTIFY_RANGE macros. See the product documentation for more information about these macros.
See also
Technical Notes by Number
Technical Notes by Category
Technical Notes by Category
I was going through this code here and:
I have no idea what the last two parameters of the sendmessage functions are and what is going on in these two parameters? the '&H200EB0' and 'APPCOMMAND_VOLUME_MUTE * &H10000' Parameters?
Here's the full code:
Ňɏssa Pøngjǣrdenlarp35.7k1111 gold badges4141 silver badges114114 bronze badges
Mark HenneryMark Hennery
1 Answer
SendMessage is a method which can be used to send a specified message to a window or windows.
Documentation is here: http://msdn.microsoft.com/en-us/library/windows/desktop/ms644950%28v=vs.85%29.aspx
The first parameter is the 'handle' (HWND) to which the message is send. The second parameter is a message id (see http://msdn.microsoft.com/en-us/library/windows/desktop/ms644927(v=vs.85).aspx#system_defined for System-Defined Messages).
The last two parameters can be used to pass more data to the receiver. - Normally both parameters have message dependent meanings.
In your case the WM_APPCOMMAND message (http://msdn.microsoft.com/en-us/library/windows/desktop/ms646275%28v=vs.85%29.aspx) is passed (here it is a keyboard command). I think the first parameter could also be NULL (according to the link above it should be a handle to the window where the user clicked the button or pressed the key), but the second one has to specify the command which should be passed (as an APPCOMMAND). The second parameter is 8 (8=APPCOMMAND_VOLUME_MUTE according to the list on the linked page), however we have to do a bitshift, because the information has to be encoded in the high-order bits of the parameter (i.e., 0x80000 - that's APPCOMMAND_VOLUME_MUTE*&H10000; see lParam section on the page I linked).
MrTuxMrTux22.3k1515 gold badges6262 silver badges100100 bronze badges
Got a question that you can’t ask on public Stack Overflow? Learn more about sharing private information with Stack Overflow for Teams.