WPF Designer Extensibility Architecture

The design environment interacts with run-time controls though a programming interface called an editing model. The editing model consists of three functional subunits: a model, a public wrapper that abstracts the model, and a view that represents the user interface (UI) of the model.

The design environment uses the ModelItem type to communicate with the underlying model. All changes are made to the ModelItem wrappers, which affect the underlying model. This allows the model to be simple. The ModelItem wrappers handle complex designer features such as transaction support, undo tracking, and change notifications.

The ModelService class provides the entry point for the editing model and for global event notifications.

The ViewService class maps visual representations to the underlying model items.

Both services are required for the designer to function. The DesignerView class, which is responsible for processing user input and routing it to commands, requires both of these services to accurately map user input back to the model.

You extend the design-time behavior of your types by using the FeatureProvider or the FeatureConnector<TFeatureProviderType> classes. The FeatureConnector<TFeatureProviderType> class manages a list of FeatureProvider objects.

The FeatureProvider class provides the most basic extensibility point. A feature provider is a lightweight feature or add-in which typically does not require much from the design environment and is created and destroyed in a given context. Features providers are used to add new bits of UI to the design surface or to modify some basic behavior. For example, a feature provider might add more grab handles or provide a new kind of mouse-drag behavior.

To access the deepest level of extensibility, derive from the FeatureConnector<TFeatureProviderType> class. This class exposes a service provider, through which derived feature connector classes can handle events and request and publish services. For example, you might implement a feature connector to provide selection UI or object-specific serialization.

In general, implement a feature to extend existing concepts. Implement a feature connector to provide new concepts. For more information, see Feature Providers and Feature Connectors.

A significant amount of state information is accumulated in a running designer. For example, your designer's state might include which objects are selected, or the behavior that occurs when the left mouse button is pressed. Designer state is stored in a central location, so that it can be found when it is needed. The EditingContext class represents this central repository of state for the designer.

The EditingContext class separates state into two categories: data and behavior. Data is stored as a table of context items and behavior is stored as a table of services. Both tables are indexed by a type-based key and are enumerable.

The ContextItem class holds a single piece of state in the designer. Context items are immutable, but new context items can replace existing context items to simulate mutability.

Services are accessed through the Services property, which returns an instance of ServiceManager, and context items are accessed through the Items property, which returns an instance of ContextItemManager.

The WPF Designer tool architecture consists of commands, tasks, and tools. 

A command is a unique identifier that represents some behavior. For example, Cut is a command which means to cut the current text and add it to the Clipboard. The code that implements Cut varies from application to application, and even varies within an application. For example, cutting text in a Word document is a different implementation than cutting text in the search text box of the same document. Regardless of implementation, the Cut command remains constant.

The WPF Designer augments the WPF command system by introducing a concept of a tool command. A tool command implements the ICommand interface and is like the RoutedCommand class.

A task has a collection of command bindings, which allows you to add routed commands. The DesignerView class has code which uses the same routing strategy as tool commands to find and execute routed commands that are defined on tasks. The DesignerView class enables tasks which support common WPF commands, such as Copy.

A tool is a class which processes user input. All user input comes into the designer as one or more input events. Those input events are passed to the currently active tool, which converts them to input bindings. If an input binding is returned, the command within the binding is executed.

A tool can represent the global mode of the designer. For example, if the user is selecting components on the design surface, that selection mode is possible because the currently active tool offers input bindings and commands that handle selection. When the user creates a new instance of a control, a different tool becomes active and offers a different set of commands, which are bound to the same input bindings.

In the WPF Designer framework, metadata defining the design-time behavior of a control is specified by attributes and factored into a separate assembly. Different designers can consume different metadata assemblies with completely different design-time implementations. This decouples the run-time and design-time behavior, so that you can revise the designer separately from the control.

To specify an assembly that provides design-time implementation, mark the assembly with the ProvideMetadataAttribute and include a class that implements the IProvideAttributeTable interface.

For more information, see Providing Design-time Metadata.