RoutedEventArgs RoutedEventArgs RoutedEventArgs RoutedEventArgs Class


Contains state information and event data associated with a routed event.

public : class RoutedEventArgs : IRoutedEventArgs
struct winrt::Windows::UI::Xaml::RoutedEventArgs : IRoutedEventArgs
public class RoutedEventArgs : IRoutedEventArgs
Public Class RoutedEventArgs Implements IRoutedEventArgs
Windows 10 requirements
Device family
Windows 10 (introduced v10.0.10240.0)
API contract
Windows.Foundation.UniversalApiContract (introduced v1)


RoutedEventArgs is a common event data type used for base element events in UWP app using C++, C#, or Visual Basic. Generally RoutedEventArgs as the event data type indicates that the event with this event data is a routed event, although there are some exceptions. For more info on routed events and how to handle them, see Events and routed events overview.

The API that RoutedEventArgs adds to a generalized event data set is OriginalSource. OriginalSource can be useful for determining the element that first raised the event for hit testing and event routing scenarios, but there are also times where the sender from the delegate signature is the more useful source object reference for a handler. For more info, see Events and routed events overview.

RoutedEventArgs and the Handled property

If you're familiar with Windows Presentation Foundation (WPF), you might know that Windows Presentation Foundation (WPF) declares a property named Handled on the RoutedEventArgs class. Certain routed event data classes in the Windows Runtime also define a Handled property, and you use it the same way you did in Windows Presentation Foundation (WPF) (it influences the event route from within your handler.) However, for Windows Runtime and also for Microsoft Silverlight this behavior is specific only to certain routed events rather than all routed events (as is true in Windows Presentation Foundation (WPF)). For example, you can set Handled if you are handling a pointer event and the event data class is PointerRoutedEventArgs, but you can't set Handled for a Loaded event where the event data is a RoutedEventArgs instance.

RoutedEventArgs derived classes

RoutedEventArgs is the parent class for several immediately derived classes that define event data for Windows Runtime events involving UI elements. Not all of the events where the classes provide data are necessarily routed events as defined in Events and routed events overview. But many are. The ones that aren't sometimes have the event data derived from RoutedEventArgs for compatibility reasons.


RoutedEventArgs() RoutedEventArgs() RoutedEventArgs() RoutedEventArgs()

Initializes a new instance of the RoutedEventArgs class.

public : RoutedEventArgs()
RoutedEventArgs() const;
public RoutedEventArgs()
Public Sub New()


OriginalSource OriginalSource OriginalSource OriginalSource

Gets a reference to the object that raised the event. This is often a template part of a control rather than an element that was declared in your app UI.

public : Platform::Object OriginalSource { get; }
winrt::Windows::Foundation::IInspectable OriginalSource();
public object OriginalSource { get; }
Public ReadOnly Property OriginalSource As object
object object

The object that raised the event.


When a routed event bubbles up an event route, sender is no longer the same object as the event-raising object. Instead, sender is the object where the handler that is being invoked is attached.

In some cases, sender is not interesting, and you are instead interested in info such as which of the possible child objects the pointer is over when a pointer event fired, or which object in a larger UI held focus when a user pressed a keyboard key. For these cases, you can use the value of the OriginalSource property. At all points on the route, OriginalSource reports the original object that fired the event, instead of the object where the handler is attached. However, for UIElement input events, that original object is often an object that is not immediately visible in the page-level UI definition XAML. Instead, that original source object might be a templated part of a control. For example, if the user hovers the pointer over the very edge of a Button, for most pointer events the OriginalSource is a Border template part in the Template, not the Button itself. Therefore, you can't always rely on OriginalSource representing an object that you specifically declared in your XAML page-level UI definitions.


Input event bubbling is especially useful if you are creating a templated control. Any control that has a template can have a new template applied by its consumer. The consumer that's trying to recreate a working template might unintentionally eliminate some event handling declared in the default template. You can still provide control-level event handling by attaching handlers as part of the OnApplyTemplate override in the class definition. Then you can catch the input events that bubble up to the control's root on instantiation.

See Also

See Also