RoutedEvent Class
Definition
Important
Some information relates to prerelease product that may be substantially modified before it’s released. Microsoft makes no warranties, express or implied, with respect to the information provided here.
Represents a routed event to the Windows Runtime event system.
public ref class RoutedEvent sealed
/// [Windows.Foundation.Metadata.ContractVersion(Windows.Foundation.UniversalApiContract, 65536)]
/// [Windows.Foundation.Metadata.MarshalingBehavior(Windows.Foundation.Metadata.MarshalingType.Agile)]
/// [Windows.Foundation.Metadata.Threading(Windows.Foundation.Metadata.ThreadingModel.Both)]
class RoutedEvent final
/// [Windows.Foundation.Metadata.ContractVersion(Windows.Foundation.UniversalApiContract, 65536)]
/// [Windows.Foundation.Metadata.MarshalingBehavior(Windows.Foundation.Metadata.MarshalingType.Agile)]
class RoutedEvent final
[Windows.Foundation.Metadata.ContractVersion(typeof(Windows.Foundation.UniversalApiContract), 65536)]
[Windows.Foundation.Metadata.MarshalingBehavior(Windows.Foundation.Metadata.MarshalingType.Agile)]
[Windows.Foundation.Metadata.Threading(Windows.Foundation.Metadata.ThreadingModel.Both)]
public sealed class RoutedEvent
[Windows.Foundation.Metadata.ContractVersion(typeof(Windows.Foundation.UniversalApiContract), 65536)]
[Windows.Foundation.Metadata.MarshalingBehavior(Windows.Foundation.Metadata.MarshalingType.Agile)]
public sealed class RoutedEvent
Public NotInheritable Class RoutedEvent
- Inheritance
- Attributes
Windows requirements
Device family |
Windows 10 (introduced in 10.0.10240.0)
|
API contract |
Windows.Foundation.UniversalApiContract (introduced in v1.0)
|
Examples
This example shows the basic syntax for wiring an event handler with AddHandler and handledEventsToo as true. In this case the event being wired is Tapped, and the RoutedEvent-type identifier used in the example is TappedEvent. The typical place to wire handlers is either Loaded for a page or OnApplyTemplate for a templated control.
void MainPage::pageRoot_Tapped(Platform::Object^ sender, Windows::UI::Xaml::Input::TappedRoutedEventArgs^ e)
{
//implementation
}
void MainPage::pageRoot_Loaded(Platform::Object^ sender, Windows::UI::Xaml::RoutedEventArgs^ e)
{
this->AddHandler(UIElement::TappedEvent, ref new TappedEventHandler(this, &MainPage::pageRoot_Tapped), true);
}
private void pageRoot_Tapped(object sender, TappedRoutedEventArgs e)
{
//implementation
}
private void pageRoot_Loaded_1(object sender, RoutedEventArgs e)
{
this.AddHandler(UIElement.TappedEvent, new TappedEventHandler(pageRoot_Tapped), true);
}
Private Sub Page_Tapped(sender As Object, e As TappedRoutedEventArgs)
' implementation
End Sub
Private Sub Page_Loaded_1(sender As Object, e As RoutedEventArgs)
Me.AddHandler(UIElement.TappedEvent, New TappedEventHandler(AddressOf Page_Tapped), True)
End Sub
Remarks
Note
The Windows Runtime event system doesn't enable you to create a custom routed event; only the Windows Runtime itself can define an event such that it has the routed event behavior.
For more info on how routed events work, see Events and routed events overview. The RoutedEvent type is part of the infrastructure for routed events, but you don't use RoutedEvent directly in typical Windows Runtime app programming.
The purpose of the RoutedEvent type is to serve as an identifier for the Windows Runtime event system, similar to how DependencyProperty provides an identifier type for the dependency property system. UIElement includes several static read-only properties of type RoutedEvent, which are named using a naming pattern. Each RoutedEvent property is named after an event plus the suffix "Event". Each such property is the identifier for the routed event that its name begins with. For example, TappedEvent identifies the Tapped routed event to the event system.
For most app code usages, simply referencing the event by name in XAML or by its code entity name in code is all that's needed to reference an event on an object, for purposes of adding or removing handlers. The RoutedEvent identifiers are only needed when you attach handlers that should be invoked even when the routed events are previously marked as handled by either system or app code. The API you use for this scenario, and the API that use a RoutedEvent value as a parameter, are UIElement.AddHandler and UIElement.RemoveHandler. For more info, see Events and routed events overview.
Events that use a RoutedEvent identifier
Here's a list of the routed events that have a RoutedEvent identifier and thus can use the UIElement.AddHandler technique we described:
- DoubleTapped
- DragEnter
- DragLeave
- DragOver
- Drop
- Holding
- KeyDown
- KeyUp
- ManipulationCompleted
- ManipulationDelta
- ManipulationInertiaStarting
- ManipulationStarted
- ManipulationStarting
- PointerCanceled
- PointerCaptureLost
- PointerEntered
- PointerExited
- PointerMoved
- PointerPressed
- PointerReleased
- PointerWheelChanged
- RightTapped
- Tapped
Note
GotFocus and LostFocus act like routed events but don't have a RoutedEvent identifier, so you can't use AddHandler with them.