[DllImport("user32.dll", CharSet = CharSet.Auto)]
static extern IntPtr SendMessage(IntPtr hWnd, UInt32 Msg, IntPtr wParam, StringBuilder lParam);
//If you use '[Out] StringBuilder', initialize the string builder with proper length first.
[DllImport("user32.dll")]
static extern IntPtr SendMessage(IntPtr hWnd, UInt32 Msg, IntPtr wParam, [MarshalAs(UnmanagedType.LPStr)] string lParam);
//Also can add 'ref' or 'out' ahead of 'String lParam', don't use CharSet.Auto since we use MarshalAs(..) in this
//example.
//Works for unicode. One can also use CharSet = CharSet.Unicode instead of [MarshalAs(UnmanagedType.LPWStr)]
[DllImport("user32.dll", EntryPoint = "SendMessageW")]
static extern IntPtr SendMessageW(IntPtr hWnd, UInt32 Msg, IntPtr wParam, [MarshalAs(UnmanagedType.LPWStr)] string lParam);
//If you want to prevent an (unreferenced) managed object from possibly being garbage collected
//during a call to SendMessage, you can wrap the handle in a HandleRef structure.
[DllImport("user32.dll", CharSet = CharSet.Auto, SetLastError = false)]
static extern IntPtr SendMessage(HandleRef hWnd, UInt32 Msg, IntPtr wParam, IntPtr lParam);
VB.NET Signature:
<DllImport("user32.dll", SetLastError:=True, CharSet:=CharSet.Auto)> _
Private Shared Function SendMessage(ByVal hWnd As IntPtr, ByVal Msg As UInteger, ByVal wParam As IntPtr, ByVal lParam As IntPtr) As IntPtr
End Function
Declare Auto Function SendMessage Lib "user32.dll" (ByVal hWnd As IntPtr, ByVal msg As Integer, ByVal wParam As IntPtr, ByVal lParam As IntPtr) As IntPtr
Common VB Overloads:
Declare Function SendMessage Lib "user32.dll" (ByVal hWnd As IntPtr, ByVal Msg As Integer,
ByVal wParam As IntPtr, ByRef lParam As StringBuilder) As IntPtr
Declare Function SendMessage Lib "user32.dll" (ByVal hWnd As IntPtr, ByVal Msg As Integer,
ByVal wParam As IntPtr, ByRef RECT As IntPtr) As IntPtr
Declare Function SendMessage Lib "user32.dll" (ByVal hWnd As IntPtr, ByVal Msg As Integer,
ByVal wParam As IntPtr, ByRef POINT As IntPtr) As IntPtr
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 replace "hWnd" with "IntPtr" instead of "HandleRef". However, you are taking a risk in doing this - it may cause your code to crash with race conditions - .NET can and will dispose your window handles out from under your message causing all sorts of nasty problems!
:::Question, for someone more knowledgable than me: Can't this last issue be addressed with marshaling, specifically pinning?
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.
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 2:43:09 AM - anfortas.geo@yahoo.com-216.204.61.86
The SendNotifyMessage API
7/30/2014 9:42:28 AM - Corvbreau@hotmail.com-137.61.234.225
The PostMessage API
4/2/2016 12:09:27 PM - -78.110.196.168
The PostThreadMessage API
11/30/2012 10:34:26 AM - -121.214.99.141
The SetLastError API
1/26/2016 3:27:33 AM - -124.148.167.58
Click to read this page
4/6/2008 7:23:14 AM - anonymous
ByVal is a VB keyword that specifies a variable to be passed as a parameter BY VALUE. In other words, if the function or sub changes the value of the internal variable, it does not change the value of the external variable that was passed to it.
4/25/2007 3:19:55 AM - josep1er@cmich.edu-141.209.229.179
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 9:41:44 AM - -212.251.139.186
ByVal is a VB keyword that specifies a variable to be passed as a parameter BY VALUE. In other words, if the function or sub changes the value of the internal variable, it does not change the value of the external variable that was passed to it.
4/25/2007 3:19:55 AM - josep1er@cmich.edu-141.209.229.179
Click to read this page
10/23/2022 7:47:26 PM - gBqsPxAZ-51.137.182.20
ByVal is a VB keyword that specifies a variable to be passed as a parameter BY VALUE. In other words, if the function or sub changes the value of the internal variable, it does not change the value of the external variable that was passed to it.
4/25/2007 3:19:55 AM - josep1er@cmich.edu-141.209.229.179
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 4:00:13 AM - Damon Carr-72.43.165.29
ByVal is a VB keyword that specifies a variable to be passed as a parameter BY VALUE. In other words, if the function or sub changes the value of the internal variable, it does not change the value of the external variable that was passed to it.
4/25/2007 3:19:55 AM - josep1er@cmich.edu-141.209.229.179
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 4:00:13 AM - Damon Carr-72.43.165.29
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 4:00:13 AM - Damon Carr-72.43.165.29
TODO - a short description
3/16/2007 8:32:35 AM - anonymous
Click to read this page
6/25/2010 2: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 4:00:13 AM - Damon Carr-72.43.165.29
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 4:00:13 AM - Damon Carr-72.43.165.29
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 4:00:13 AM - Damon Carr-72.43.165.29
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 4:00:13 AM - Damon Carr-72.43.165.29
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 4:00:13 AM - Damon Carr-72.43.165.29
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 4:00:13 AM - Damon Carr-72.43.165.29
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 4:00:13 AM - Damon Carr-72.43.165.29
Click to read this page
6/25/2010 2:17:25 PM - -90.152.60.34
Click to read this page
6/25/2010 2: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 4:00:13 AM - Damon Carr-72.43.165.29
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.