User Input and Presentation Architecture
[This documentation is for preview only, and is subject to change in later releases. Blank topics are included as placeholders.]
When building a designer, there are several issues that must be solved with regard to user input. For example, control of element focus, routing of mouse and keyboard inputs, adding adorners, and invoking commands must all have a common and centralized mechanism of handling user input. In the WPF Designer for Visual Studio, the DesignerView class provides management for all these issues and is the class that represents the primary design surface.
Adorners
Adorners are visual elements that appear only in Design view and are used to aid the design process. For example, resize handles around controls when the control is selected are an example of an adorner. The DesignerView class contains an Adorners collection where adorners can be added and used in Design view. For more information about adorners, see Adorner Architecture.
Input Routing
The DesignerView class provides a standard, centralized method for routing user input. The input process consists of the following generalized steps:
Input event occurs.
Perform hit testing.
Find an input binding.
Execute command binding.
The following sections examine these steps in more detail.
Input Event Occurs
When an input event occurs, it is routed to the DesignerView class, where hit testing is performed.
Perform Hit Testing
When an input event arrives to the DesignerView instance, a hit test scan is performed. Hit testing scans visuals in both the adorner layer and the object hierarchy and returns the following information:
What adorner the mouse is over.
What model item the adorner is associated with.
The visual the mouse is over, if not an adorner.
The model item associated with the visual.
Find an Input Binding
After hit testing, DesignerView tries to match an input event to an input binding. The algorithm that is used to find an input binding varies according to the current state of the designer:
If the currently active tool has an active task, only that task's input bindings are searched for a binding that matches the input event.
For mouse input, DesignerView examines the hit tested adorner looking for a task that has an input binding that matches the input event. If a capture has been taken, the adorner used is the adorner that was hit tested when the capture was taken. If no adorner was hit tested, DesignerView will walk the input bindings of the tasks that are contained in the active tool.
For keyboard input, DesignerView walks the input bindings of the tasks that are contained in the active tool. Keyboard input bindings on adorners are ignored.
Note
Modifier keys for mouse input are not ignored. Modifier keys work fine with mouse input.
Execute Command Binding
Once an input binding is obtained, the Execute method is called on the command in the binding. However, commands are interfaces, so the behavior of Execute is up to the implementation of that command.