eventName An unqualified event name, equivalent to the Name property of the RoutedEvent field, not the actual member name of the RoutedEvent identifier field within a type. Without qualification, eventName must name an event as found in the type that is the TargetType of the current style containing the EventSetter or EventTrigger. type The type to use to qualify the event name. If provided without a prefix, type is expected to be a class or structure within the default namespace. For custom events, or events that are on types outside of the default namespace (typically the default is the WPF namespace), this type can be prefixed with a mapped xmlns namespace that contains the type with the desired routed event identifier. For details on namespace mapping, see XAML Namespaces and Namespace Mapping.

This class has a XAML usage that is exclusively intended for providing the value of the RoutedEvent property of an EventTrigger (or derived class), or for the Event property of an EventSetter (or derived class). For more information about EventTrigger, EventSetter, and the XAML usages for those classes, see Routed Events Overview.

For your custom event to support event routing, you need to register a RoutedEvent using the RegisterRoutedEvent method. This example demonstrates the basics of creating a custom routed event.

As shown in the following example, you first register a RoutedEvent using the RegisterRoutedEvent method. By convention, the RoutedEvent static field name should end with the suffix Event. In this example, the name of the event is Tap and the routing strategy of the event is Bubble. After the registration call, you can provide add-and-remove common language runtime (CLR) event accessors for the event.

Note that even though the event is raised through the OnTap virtual method in this particular example, how you raise your event or how your event responds to changes depends on your needs.

Note also that this example basically implements an entire subclass of Button; that subclass is built as a separate assembly and then instantiated as a custom class on a separate Extensible Application Markup Language (XAML) page. This is to illustrate the concept that subclassed controls can be inserted into trees composed of other controls, and that in this situation, custom events on these controls have the very same event routing capabilities as any native Windows Presentation Foundation (WPF) element does.