In WPF we have routed events. When should these be used instead of regular events?
相关问题
- VNC control for WPF application
- Stop child process when parent process stops
- Fire resize event once not based on timing
- WPF Binding from System.Windows.SystemParameters.P
- XAML: Applying styles to nested controls
In WPF control composition is highly used. which mandates to use Routed event, because composition of set of controls exposes single activity most of the time.
Routed events have special behavior, but that behavior is largely invisible if you are handling an event on the element where it is raised.
Where routed events become powerful is if you use any of the suggested scenarios: defining common handlers at a common root, compositing your own control, or defining your own custom control class.
Routed event listeners and routed event sources do not need to share a common event in their hierarchy. Any UIElement or ContentElement can be an event listener for any routed event. Therefore, you can use the full set of routed events available throughout the working API set as a conceptual "interface" whereby disparate elements in the application can exchange event information. This "interface" concept for routed events is particularly applicable for input events.
Routed events can also be used to communicate through the element tree, because the event data for the event is perpetuated to each element in the route. One element could change something in the event data, and that change would be available to the next element in the route.
Other than the routing aspect, there are two other reasons that any given WPF event might be implemented as a routed event instead of a standard CLR event. If you are implementing your own events, you might also consider these principles:
Source: MSDN: Routed Events Overview