Overview of using the mouse (Windows Forms .NET)
Receiving and handling mouse input is an important part of every Windows application. You can handle mouse events to carry out an action in your application, or use mouse location information to perform hit testing or other actions. Also, you can change the way the controls in your application handle mouse input. This article describes these mouse events in detail, and how to obtain and change system settings for the mouse.
The Desktop Guide documentation for .NET 7 and .NET 6 is under construction.
In Windows Forms, user input is sent to applications in the form of Windows messages. A series of overridable methods process these messages at the application, form, and control level. When these methods receive mouse messages, they raise events that can be handled to get information about the mouse input. In many cases, Windows Forms applications can process all user input simply by handling these events. In other cases, an application may override one of the methods that process messages to intercept a particular message before it's received by the application, form, or control.
All Windows Forms controls inherit a set of events related to mouse and keyboard input. For example, a control can handle the MouseClick event to determine the location of a mouse click. For more information on the mouse events, see Using mouse events.
Mouse location and hit-testing
When the user moves the mouse, the operating system moves the mouse pointer. The mouse pointer contains a single pixel, called the hot spot, which the operating system tracks and recognizes as the position of the pointer. When the user moves the mouse or presses a mouse button, the Control that contains the HotSpot raises the appropriate mouse event.
You can obtain the current mouse position with the Location property of the MouseEventArgs when handling a mouse event or by using the Position property of the Cursor class. You can then use mouse location information to carry out hit-testing, and then perform an action based on the location of the mouse. Hit-testing capability is built in to several controls in Windows Forms such as the ListView, TreeView, MonthCalendar and DataGridView controls.
Used with the appropriate mouse event, MouseHover for example, hit-testing is very useful for determining when your application should do a specific action.
Changing mouse input settings
You can detect and change the way a control handles mouse input by deriving from the control and using the GetStyle and SetStyle methods. The SetStyle method takes a bitwise combination of ControlStyles values to determine whether the control will have standard click, double-click behavior, or if the control will handle its own mouse processing. Also, the SystemInformation class includes properties that describe the capabilities of the mouse and specify how the mouse interacts with the operating system. The following table summarizes these properties.
|Gets the dimensions, in pixels, of the area in which the user must click twice for the operating system to consider the two clicks a double-click.
|Gets the maximum number of milliseconds that can elapse between a first click and a second click for the mouse action to be considered a double-click.
|Gets the number of buttons on the mouse.
|Gets a value indicating whether the functions of the left and right mouse buttons have been swapped.
|Gets the dimensions, in pixels, of the rectangle within which the mouse pointer has to stay for the mouse hover time before a mouse hover message is generated.
|Gets the time, in milliseconds, that the mouse pointer has to stay in the hover rectangle before a mouse hover message is generated.
|Gets a value indicating whether a mouse is installed.
|Gets a value indicating the current mouse speed, from 1 to 20.
|Gets a value indicating whether a mouse with a mouse wheel is installed.
|Gets the amount of the delta value of the increment of a single mouse wheel rotation.
|Gets the number of lines to scroll when the mouse wheel is rotated.
Methods that process user input messages
Forms and controls have access to the IMessageFilter interface and a set of overridable methods that process Windows messages at different points in the message queue. These methods all have a Message parameter, which encapsulates the low-level details of Windows messages. You can implement or override these methods to examine the message and then either consume the message or pass it on to the next consumer in the message queue. The following table presents the methods that process all Windows messages in Windows Forms.
|This method intercepts queued (also known as posted) Windows messages at the application level.
|This method intercepts Windows messages at the form and control level before they have been processed.
|This method processes Windows messages at the form and control level.
|This method performs the default processing of Windows messages at the form and control level. This provides the minimal functionality of a window.
|This method intercepts messages at the form and control level, after they've been processed. The EnableNotifyMessage style bit must be set for this method to be called.