Clickevent is one of the
Buttonelements, and whichever
Buttonwas clicked is the first element that has the opportunity to handle the event. But if no handler attached to the
Buttonacts on the event, then the event will bubble upwards to the
Buttonparent in the element tree, which is the
StackPanel. Potentially, the event bubbles to
Border, and then beyond to the page root of the element tree (not shown).
Button, which effectively extends the visual tree of the button. However, the added image must not break the hit-testing behavior that causes a button to respond to a
Clickof its content, even if the user clicks on pixels that are technically part of the image.
RoutedEventfield as an identifier, which provides a robust event identification technique that does not require static or run-time reflection.
RoutedEventclass and registered with the Avalonia event system.
RoutedEventinstance obtained from registration is typically retained as a
readonlyfield member of the class that registers and thus "owns" the routed event. The connection to the identically named CLR event (which is sometimes termed the "wrapper" event) is accomplished by overriding the
removeimplementations for the CLR event. Ordinarily, the
removeare left as an implicit default that uses the appropriate language-specific event syntax for adding and removing handlers of that event. The routed event backing and connection mechanism is conceptually similar to how an avalonia property is a CLR property that is backed by the
AvaloniaPropertyclass and registered with the Avalonia property system.
Taprouted event, including the registration and exposure of the
RoutedEventidentifier field and the
removeimplementations for the
publicmethods. We hope to remove this restriction in future.
b1SetColoris the name of the implemented handler that contains the code that handles the
b1SetColormust have the same signature as the
RoutedEventHandler<RoutedEventArgs>delegate, which is the event handler delegate for the
Clickevent. The first parameter of all routed event handler delegates specifies the element to which the event handler is added, and the second parameter specifies the data for the event.
RoutedEventHandler<RoutedEventArgs>is the basic routed event handler delegate. For routed events that are specialized for certain controls or scenarios, the delegates to use for the routed event handlers also might become more specialized, so that they can transmit specialized event data. For instance, in a common input scenario, you might handle a
PointerPressedrouted event. Your handler should implement the
RoutedEventHandler<PointerPressedEventArgs>delegate. By using the most specific delegate, you can process the
PointerPressedEventArgsin the handler and read the
PointerEventArgs.Pointerproperty, which contains information about the pointer that caused the press.
AddHandler(which is the same method that the existing backing calls for
add.) However, existing Avalonia routed events generally have backing implementations of
removelogic that allow the handlers for routed events to be added by a language-specific event syntax, which is more intuitive syntax than the helper method. The following is an example usage of the helper method:
Handledproperty, which takes a Boolean value. The purpose of the
Handledproperty is to enable any event handler along the route to mark the routed event as handled, by setting the value of
true. After being processed by the handler at one element along the route, the shared event data is again reported to each listener along the route.
Handledaffects how a routed event is reported or processed as it travels further along the route. If
truein the event data for a routed event, then handlers that listen for that routed event on other elements are generally no longer invoked for that particular event instance. This is true both for handlers attached in XAML and for handlers added by language-specific event handler attachment syntaxes such as
+=. For most common handler scenarios, marking an event as handled by setting
truewill "stop" routing for either a tunneling route or a bubbling route, and also for any event that is handled at a point in the route by a class handler.
truein the event data. In other words, the event route is not truly stopped by marking the event data as handled. You can only use the handledEventsToo mechanism in code:
AddHandler<TEventArgs>(RoutedEvent<TEventArgs>, EventHandler<TEventArgs> handler, RoutingStrategies, bool)to add your handler. Specify the value of
Handledstate produces in routed events, the concept of
Handledhas implications for how you should design your application and write the event handler code. You can conceptualize
Handledas being a simple protocol that is exposed by routed events. Exactly how you use this protocol is up to you, but the conceptual design for how the value of
Handledis intended to be used is as follows:
true. (Or, it is of course possible that the current listener is the first point in the route.) Handlers on the current listener now have three possible courses of action:
Handled=truein its event data, so only
handledEventsToolisteners have the opportunity to invoke further handlers.
AvaloniaObject, you can also define and attach a class handler for a routed event that is a declared or inherited event member of your class. Class handlers are invoked before any instance listener handlers that are attached to an instance of that class, whenever a routed event reaches an element instance in its route.
AddClassHandlermethod from a static constructor:
Gestures.Tappedcan more easily be handled on any given
Tappedon that control rather than dealing with attached event syntax either in XAML or code.
StackPanel. However, it is adding a handler for a routed event that was declared and will be raised by the
Button"owns" the event, but the routed event system permits handlers for any routed event to be attached to any control instance listener that could otherwise attach listeners for a common language runtime (CLR) event. The default xmlns namespace for these qualified event attribute names is typically the default Avalonia xmlns namespace, but you can also specify prefixed namespaces for custom routed events.
RaiseEventmethod call in the implementing class that raises the bubbling event listens for the event data from the tunneling event and reuses it in the new raised event. Listeners with handlers for the tunneling event have the first opportunity to mark the routed event handled (class handlers first, then instance handlers). If an element along the tunneling route marked the routed event as handled, the already-handled event data is sent on for the bubbling event, and typical handlers attached for the equivalent bubbling input events will not be invoked. To outward appearances it will be as if the handled bubbling event has not even been raised. This handling behavior is useful for control compositing, where you might want all hit-test based input events or focus-based input events to be reported by your final control, rather than its composite parts. The final control element is closer to the root in the compositing, and therefore has the opportunity to class handle the tunneling event first and perhaps to "replace" that routed event with a more control-specific event, as part of the code that backs the control class.
leaf element #2is the source of a
PointerPressed(tunnel) on root element.
PointerPressed(tunnel) on intermediate element #1.
PointerPressed(tunnel) on source element #2.
PointerPressed(bubble) on source element #2.
PointerPressed(bubble) on intermediate element #1.
PointerPressed(bubble) on root element.
senderparameter. The object where the event was first raised is reported by the
Sourceproperty in the event data. A routed event can still be raised and handled by the same object, in which case
Sourceare identical (this is the case with Steps 3 and 4 in the event processing example list).
Sourceis one of their child elements. When it is important to know what the source element is, you can identify the source element by accessing the
Handled, further handlers are not invoked. Typically, you should mark input events as handled as soon as a handler is invoked that addresses your application-specific logical handling of the meaning of the input event.
Handledstate is that input event handlers that are registered to deliberately ignore
Handledstate of the event data would still be invoked along either route.