Invoking Win32 SendMessge

[Zytan]

Most code on the net is wrong. This is SendMessage():
LRESULT SendMessage(HWN D hWnd, UINT Msg, WPARAM wParam, LPARAM
lParam);

All of those parameters are 32/64-bit in size depending on the
compiler, except for UINT which is a C int, which is always 32-bit,
even on a 64-bit machine, AFAIK. Most code on the net uses C# int (32-
bit) for all (or some) of these, when it should use IntPtr, which is
32/64-bit.

Now, I've seen code use HandleRef for the hWnd, instead of IntPtr, but
I cannot pass Control.Handle into a HandleRef, since it returns
IntPtr. So, should I stick with IntPtr? Or is HandleRef better?

Also, I want to do this:

const IntPtr SB_BOTTOM = 7;

But, C# doesn't allow me to make IntPtr constant, like I could do with
int! AND I cannot just store 7 into an IntPtr, since it's a type
conversion. Dammit. Is there another 32/64 integer data type that I
could use in place of IntPtr that IS allowed to be constant, which
acts like an int?

I am surprised at how annoying all of this is. No wonder people just
use int (and wait for their app to blow up on 64-bit).

Zytan

[Zytan]

Managed code compiled as anycpu(platform :anycpu - is default) will automatically run in a 32

bit process on a 32 bit OS, and as a 64 bit process on 64 bit.
Managed code compiled as 32 bit (platform:x86), will always run as 32bit irrespective the OS
version.
Managed code compiled as 64 bit (platform:x64 or itanium), will run as 64, and this only on
X64 or IA64.
A 32 bit process will automatically get the 32 bit version of user32.dll loaded by the OS
loader, while a 64 bit version will load the 64 bit version, a 32 and 64 bit code mix isn't
possible in the same process, this means that you need to declare all machine dependent
int's as IntPtr to be portable between 32 and 64 bit, the rest is taken care of by the OS.

Thanks, Willy. Just to be clear, the default compilation in VC# 2005
(Express) is platform:anycpu , which means it will chage IntPtr to the
proper size at runtime? Also, IntPtr is always the proper thing to
use, just as INT_PTR is in VC++, so that it will work if compiled on
32-bit, or compiled on 64-bit, or compiled as 32/64-bit
(platform:anycp u)?

Zytan

[Willy Denoyette [MVP]]

"Zytan" <zy**********@y ahoo.comwrote in message
news:11******** **************@ c51g2000cwc.goo glegroups.com.. .

>Managed code compiled as anycpu(platform :anycpu - is default) will automatically run in a
32
bit process on a 32 bit OS, and as a 64 bit process on 64 bit.
Managed code compiled as 32 bit (platform:x86), will always run as 32bit irrespective the
OS
version.
Managed code compiled as 64 bit (platform:x64 or itanium), will run as 64, and this only
on
X64 or IA64.
A 32 bit process will automatically get the 32 bit version of user32.dll loaded by the OS
loader, while a 64 bit version will load the 64 bit version, a 32 and 64 bit code mix
isn't
possible in the same process, this means that you need to declare all machine dependent
int's as IntPtr to be portable between 32 and 64 bit, the rest is taken care of by the
OS.

Thanks, Willy. Just to be clear, the default compilation in VC# 2005
(Express) is platform:anycpu , which means it will chage IntPtr to the
proper size at runtime? Also, IntPtr is always the proper thing to
use, just as INT_PTR is in VC++, so that it will work if compiled on
32-bit, or compiled on 64-bit, or compiled as 32/64-bit
(platform:anycp u)?

Zytan

Yep, it's always the proper thing to use where machine dependent integers are expected.
These include pointer types like HANDLE and HWND but also opaque types like WPARAM, LPARAM,
LRESULT etc..

Willy.