The screen builds an InputContext instance that gets passed to each control during input handling. This context provides a few very useful pieces of information, most notably the property MousePosition. This is the mouse position relative to the control considering any render transformation that may be applied to the control. That means, the control can read the MousePosition input and use it as if it was not scaled/rotated/translated. In contrast, ScreenMousePosition is the absolute mouse position on the screen.

The input context is also useful to hand down information to visual children. For example, each control can set the AllowedPlayer property to determine from which game pad it reads input. The allowed player is part of the input context because each control needs to know the allowed player of ancestors in the visual tree. Usually controls accept input from any game pad. But in some cases (e.g. split screen games), you might want to create a window that accepts only input from player 1 and not from player 2.

Each control has a virtual method HitTest. This method is called during the input handling to check if the mouse is over the control. Per default, the hit test method returns true if the mouse is over the rectangular area (UIControlActualBounds) of the control.

HitTest is also called to determine if the mouse is over a child control and this information is stored in InputContextIsMouseOver and passed to the child control. This is important for controls that clip the space of the child controls, like a scroll viewer. For example, a control could be outside the visible viewport of a scroll viewer. By checking IsMouseOver of the input context the control sees that mouse cannot be over this control because the mouse is either not over the parent control, or the control is clipped by the parent control.

You can override HitTest in custom controls to create round buttons or other non-rectangular clickable areas.

When a control handles keyboard input, it must let the other controls and other game logic know that the key presses have been handled. Here are a few examples:

• A window contains a multi-line text box and a button where ButtonIsDefault is true (this means the button is activated when the user presses ENTER if the focus is within the window). If the text box has input focus and the user presses ENTER, then the key press is handled by the text box and a newline is created in the text box. In this case the button should not react to the ENTER press.
• If there are several windows overlapping and the mouse is clicked in the top-most window, then the windows below must know that the mouse click was already handled. (You cannot click through a window.)

For this, the IInputService has several flags: IsKeyboardHandled, IsMouseOrTouchHandled, IsGamePadHandled and IsAccelerometerHandled. These flags can be read to see if the input from this device has already been handled by someone else in this frame. Controls or other game logic objects that handle input from a device should set the flags accordingly, to let other objects know that device input has been handled.

Some controls can also simply ignore these flags and handle the input nevertheless; for example, a context menu will always close when ESCAPE is pressed – no matter if any other object handles ESCAPE too.

To customize the input handling, you can derive a class from an existing control class and override OnHandleInput. Don’t forget to call base.OnHandleInput(context); because this lets the visual children do the input handling. The basic structure of OnHandleInput is

protected override void OnHandleInput(InputContext context)
{
  // Do some stuff before the child control handle input.
  ...
   
  // Call base class, which also calls child controls.
  base.OnHandleInput(context);
 
  // Do some stuff after the child controls have handled input.
  ...
}

Any code before base.OnHandleInput(context) acts before the child controls have a chance to handle input. This is used, for example, by the Window class: If the user is currently dragging the window with the mouse, then the window sets IInputService.IsMouseOrTouchHandled to true before base.OnHandleInput(context). This lets the child controls know that they should ignore mouse input.

There are also two UIControl events that you can attach to instead of overriding OnHandleInput:

• InputProcessing is raised before OnHandleInput is called.
• InputProcessed is raised after OnHandleInput is called.