Type a page name and press Enter. You'll jump to the page if it exists, or you can create it if it doesn't.
To create a page in a module other than user32, prefix the name with the module name and a period.

SendMessage (user32)

.

Summary

Sends the specified message to a window or windows. It calls the window procedure for the specified window and does not return until the window procedure has processed the message.

Notes:

2) NEVER use "int" or "integer" as lParam. Your code WILL crash on 64-bit windows. ONLY use IntPtr, a "ref" structure, or an "out" structure.

3) NEVER use "bool", "int", or "integer" as the return value. Your core WILL crash on 64-bit windows. ONLY use IntPtr. It's not safe to use bool - pInvoke cannot marshal an IntPtr to a boolean.

4) Use "IntPtr" as the return value, EVEN if the message says it doesn't return any useful information.

5) Microsoft defines the Msg member of the System.Windows.Forms.Message structure to be System.Int32[1]. At the same time the SendMessage native API defines message as type UINT[2], which is a 32-bit unsigned value.[3]

6) You can safely type "hWnd" as an "IntPtr" instead of a "HandleRef", but make sure you understand what you are doing. If you are operating on a window handle provided by an unmanaged component or external application, things will just work (as well as can ever be guaranteed when other apps are free to manipulate the window themselves). However, using IntPtr with managed forms and controls may cause your code to crash under race conditions, because .NET can and will dispose of your window handle during the call. Used properly, GC.KeepAlive() can help with this. None of this has anything to do with pinning, which would NOT help here. Pinning is about keeping data from moving around; using a HandleRef or GC.KeepAlive is about preventing the runtime from destroying your handle.

7) When passing integer values to lParam and wParam, use IntPtr as they get <MarshalAs(UnmanagedType.SysInt)> attributes by default. You should avoid mixing IntPtr and Integer as parameter types. Use IntPtr.

8) The wParam and lParam paramters are defined as type WPARAM and LPARAM respectivly

WPARAM is defined as UINT_PTR
LPARAM is defined as LONG_PTR

LONG_PTR is "Signed long type for pointer precision." and is a signed 32-bit or signed 64-bit depending on the platform.

UINT_PTR is "Unsigned INT_PTR", and is unsigned 32-bit or unsigned 64-bit depending on the platform.

public static void SetTextBoxTabStopLength(TextBox tb, int tabSizeInCharacters)
{
// 1 means all tab stops are the the same length
// This means lParam must point to a single integer that contains the desired tab length
const uint regularLength = 1;

// A dialog unit is 1/4 of the average character width
int length = tabSizeInCharacters * unitsPerCharacter;

Alternative Managed API:

What about managed types marshaled to unmanaged ones? Will they cause memory leaks? Who is responsible of freeing the given unmanaged objects?

The SendMessageCallback API

2/18/2010 9:43:09 AM - -62.90.214.34

The SendNotifyMessage API

7/30/2014 3:42:28 PM - 76.184.207.111

The PostMessage API

4/2/2016 6:09:27 PM - -5.18.189.120

The PostThreadMessage API

11/30/2012 5:34:26 PM - -128.170.224.11

An IntPtr is a pointer to a memory location (unmanaged) that adapts to the platform it is running on (64-bit, etc.) UNLIKE a standard int/Integer. You should always use this type for unmanaged calls that require it, even though an int will appear to work on your development machine.

1/13/2008 11:00:13 AM - tsahi-62.219.227.88

TODO - a short description

3/16/2007 2:32:35 PM - -80.202.213.210

Click to read this page

6/25/2010 8:17:25 PM - -90.152.60.34

An IntPtr is a pointer to a memory location (unmanaged) that adapts to the platform it is running on (64-bit, etc.) UNLIKE a standard int/Integer. You should always use this type for unmanaged calls that require it, even though an int will appear to work on your development machine.

1/13/2008 11:00:13 AM - tsahi-62.219.227.88

An IntPtr is a pointer to a memory location (unmanaged) that adapts to the platform it is running on (64-bit, etc.) UNLIKE a standard int/Integer. You should always use this type for unmanaged calls that require it, even though an int will appear to work on your development machine.

1/13/2008 11:00:13 AM - tsahi-62.219.227.88

An IntPtr is a pointer to a memory location (unmanaged) that adapts to the platform it is running on (64-bit, etc.) UNLIKE a standard int/Integer. You should always use this type for unmanaged calls that require it, even though an int will appear to work on your development machine.

1/13/2008 11:00:13 AM - tsahi-62.219.227.88

An IntPtr is a pointer to a memory location (unmanaged) that adapts to the platform it is running on (64-bit, etc.) UNLIKE a standard int/Integer. You should always use this type for unmanaged calls that require it, even though an int will appear to work on your development machine.

1/13/2008 11:00:13 AM - tsahi-62.219.227.88

A HandleRef is essentially an IntPtr to a handle and a reference to the object the handle belongs to. Using HandleRef prevents the GC from collecting the object until the native method is done with it.

7/22/2009 3:41:44 PM - -212.251.139.186

An IntPtr is a pointer to a memory location (unmanaged) that adapts to the platform it is running on (64-bit, etc.) UNLIKE a standard int/Integer. You should always use this type for unmanaged calls that require it, even though an int will appear to work on your development machine.

1/13/2008 11:00:13 AM - tsahi-62.219.227.88

An IntPtr is a pointer to a memory location (unmanaged) that adapts to the platform it is running on (64-bit, etc.) UNLIKE a standard int/Integer. You should always use this type for unmanaged calls that require it, even though an int will appear to work on your development machine.

1/13/2008 11:00:13 AM - tsahi-62.219.227.88

An IntPtr is a pointer to a memory location (unmanaged) that adapts to the platform it is running on (64-bit, etc.) UNLIKE a standard int/Integer. You should always use this type for unmanaged calls that require it, even though an int will appear to work on your development machine.

1/13/2008 11:00:13 AM - tsahi-62.219.227.88

An IntPtr is a pointer to a memory location (unmanaged) that adapts to the platform it is running on (64-bit, etc.) UNLIKE a standard int/Integer. You should always use this type for unmanaged calls that require it, even though an int will appear to work on your development machine.

1/13/2008 11:00:13 AM - tsahi-62.219.227.88

Click to read this page

6/25/2010 8:17:25 PM - -90.152.60.34

Click to read this page

6/25/2010 8:17:25 PM - -90.152.60.34

An IntPtr is a pointer to a memory location (unmanaged) that adapts to the platform it is running on (64-bit, etc.) UNLIKE a standard int/Integer. You should always use this type for unmanaged calls that require it, even though an int will appear to work on your development machine.

1/13/2008 11:00:13 AM - tsahi-62.219.227.88

An IntPtr is a pointer to a memory location (unmanaged) that adapts to the platform it is running on (64-bit, etc.) UNLIKE a standard int/Integer. You should always use this type for unmanaged calls that require it, even though an int will appear to work on your development machine.

1/13/2008 11:00:13 AM - tsahi-62.219.227.88

TODO - a short description

2/26/2015 3:15:55 PM - -115.161.255.247

Please edit this page!

Do you have...

helpful tips or sample code to share for using this API in managed code?

corrections to the existing content?

variations of the signature you want to share?

additional languages you want to include?

Select "Edit This Page" on the right hand toolbar and edit it! Or add new pages containing supporting types needed for this API (structures, delegates, and more).