Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
Working with C# in Visual Studio 2008 (.NET 3.5). Looking into System.Windows.Forms.MouseEventArgs.
I’m seeing strange behavior with long Panel when I intercept handle the MouseMove event. It appears that MouseEventArgs.X goes from 0 to 32767, and wraps around to -32768.
When I watch the variable in Visual Studio, it claims that it’s of type int.
Apparently it’s a 16-bit signed integer the way it’s behaving. Is this true? Is this a hard limit?
Thanks!
This probably comes from the fact that Windows Forms is basically a .NET wrapper around the C Windows API. For the WM_MOUSEMOVE and related messages (WM_LBUTTONDOWN, etc.), the mouse coordinates are sent in the LPARAM parameter. LPARAM is a typedef for LONG_PTR, which on 32-bit Windows (only) is in turn a typedef for long. As the docs for WM_MOUSEMOVE say, you can get the cursor position by using the GET_X_LPARAM and GET_Y_LPARAM macros, which return the low-order int and the high-order int, respectively.
Since the value is 32 bits to start with (on 32-bit Windows), the only way this makes sense is for the x and y coordinates to actually be 16-bit values. Based on the definition of GET_X_LPARAM in windowsx.h, I would also guess (but do not have an official source that says) that even on x64 only the lower 32 bits of the LPARAM are used for the mouse coordinates.