#591 – You Can Attach Any Routed Event to Any Control

June 29, 2012 1 Comment

When you attach an event handler to a control, you most typically attach a handler for an event that is defined for that control.  For example, the Button control has a Click event defined.

<Button Content="Like" Click="Button_Click"/>

In WPF, however, you can actually attach any routed event to any control–whether or not that control defines the event or not.  For example, we can attach a handler for the Click event to a StackPanel object, using the full name for the ButtonBase.Click event.

A control won’t normally fire events that it doesn’t define, except that when events are routed, they can fire on every control higher up (or down) in the logical tree.

    <StackPanel ButtonBase.Click="StackPanel_Click">
        <Button Content="Like" Click="Button_Click"/>
    </StackPanel>

Now, when you click on the Button, both handlers that you define will see the Click event, because it bubbles up the logical tree.

Advertisement

Filed under Events Tagged with , ,

#590 – Not All Routed Events Exist in Pairs

June 28, 2012 Leave a comment

Many of the routed events defined for common user interface elements in WPF exist in pairs–with an Xyz event that is bubbling and a corresponding PreviewXyz event that is tunneling.  But there are also many routed events that exist without a corresponding paired event.

For example, the Click event, defined in ButtonBase is a routed event that is a bubbling event.  When a user clicks on a Button, the Click event fires on the Button and then propagates up the logical and visual trees.

Filed under Events Tagged with , ,

#589 – Standard Tunneling/Bubbling Event Pairs

June 27, 2012 1 Comment

Here are the the most important paired tunneling/bubbling events for UIElement objects:

  • PreviewDragEnter / DragEnter – Dragging something onto element
  • PreviewDragLeave / DragLeave – Dragging something off of element
  • PreviewDragOver / DragOver – Dragging something over element
  • PreviewDrop / Drop – Drop something on element after dragging
  • PreviewGiveFeedback/ GiveFeedback – Dragging starts, element sends info to source
  • PreviewGotKeyboardFocus / GotKeyboardFocus – Element gains keyboard focus
  • PreviewKeyDown / KeyDown – Key pressed while element has focus
  • PreviewKeyUp / KeyUp – Key released
  • PreviewLostKeyboardFocus / LostKeyboardFocus – Element loses keyboard focus
  • PreviewMouseDown / MouseDown – Mouse button pressed while over element
  • PreviewMouseLeftButtonDown / MouseLeftButtonDown – left mouse button pressed
  • PreviewMouseLeftButtonUp / MouseLeftButtonUp – left mouse button released
  • PreviewMouseMove / MouseMove – mouse moves over element
  • PreviewMouseRightButtonDown / MouseRightButtonDown – right mouse button pressed
  • PreviewMouseRightButtonUp / MouseRightButtonUp – right mouse button released
  • PreviewMouseUp / MouseUp – mouse button released
  • PreviewMouseWheel / MouseWheel – mouse wheel rotated
  • PreviewQueryContinueDrag / QueryContinueDrag – keyboard/mouse changes while dragging
  • PreviewTextInput / TextInput – element gets text
  • PreviewTouchDown / TouchDown – finger touches element
  • PreviewTouchMove / TouchMove – finger moves over element
  • PreviewTouchUp / TouchUp – finger raised while over element

Filed under Events Tagged with , ,

#588 – If You Handle PreviewKeyDown Event, KeyDown Won’t Fire

June 26, 2012 9 Comments

The PreviewKeyDown and KeyDown events in WPF are paired routed events.  When a user presses a key in a control, the PreviewKeyDown event fires first, as a tunneling event.  When the event has propagated down the logical tree to the control where the key press originated, the KeyDown event fires.  KeyDown propagates up the logical tree, since it is defined as a bubbling event.

If you handle the PreviewKeyDown event as it is propagating down the tree and you mark the event as handled (setting KeyEventArgs.Handled to true), the PreviewKeyDown event will not continue propagating down the tree.

But if you mark PreviewKeyDown as handled, the corresponding KeyDown event will not fire at all.  This works because the two events share the same instance of a KeyEventArgs object, so when PreviewKeyDown marks the event as handled, KeyDown also treats the event as handled.

Filed under Events Tagged with , , , , , ,

#587 – The Purpose of Tunneling and Bubbling Events

June 25, 2012 Leave a comment

Many predefined routed events in WPF are available as pairs of events–one tunneling and one bubbling.  The tunneling event typically fires first.  E.g. PreviewKeyDown and KeyDown.

Tunneling events are useful if you want to do some filtering out of different events, for example filtering out disallowed keystrokes.  This might be useful to do in a higher-level parent control, so lower level controls like buttons don’t have to all deal with the invalid input.

 

Filed under Events Tagged with , , , ,

#586 – Bubbling and Tunneling Events Are Typically Paired

June 22, 2012 4 Comments

Events defined for preexisting controls in WPF (e.g. a Button) are typically routed events–meaning that the event is propagated up or down the logical tree.  Routed events can either be bubbling events (they propagate up the tree) or tunneling events (they propagate down the tree).

Many events in WPF related to user input are available in pairs, with both a bubbling and a corresponding tunneling event.  For example, the KeyDown event (bubbling) has a corresponding PreviewKeyDown event (tunneling).

When events are paired, the tunneling events will typically fire first, followed by the paired bubbling event.

  1. User presses key
  2. Main Window sees PreviewKeyDown
  3. Outer StackPanel sees PreviewKeyDown
  4. Inner StackPanel sees PreviewKeyDown
  5. TextBox sees PreviewKeyDown
  6. TextBox sees KeyDown
  7. Inner StackPanel sees KeyDown
  8. Outer StackPanel sees KeyDown
  9. Main Window sees KeyDown

Filed under Events Tagged with , , , , , ,

#585 – Tunneling Events Propagate Down the Logical Tree

June 21, 2012 Leave a comment

In WPF, bubbling events originate in the control where the event occurred and then propagate up the logical or visual tree.  By contrast, tunneling events will be seen first by controls at the top of the hierarchy and then propagate down until they reach the control where the event originated.

<Window
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:Microsoft_Windows_Themes="clr-namespace:Microsoft.Windows.Themes;assembly=PresentationFramework.Aero"
    xmlns:loc="clr-namespace:WpfApplication11"
    xmlns:sys="clr-namespace:System;assembly=mscorlib"
    xmlns:d="http://schemas.microsoft.com/expression/blend/2008" xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
    x:Class="WpfApplication11.MainWindow"
    x:Name="Window" Title="Routed Events" Width="400"
    PreviewKeyDown="winMain_PreviewKeyDown">

    <StackPanel Name="spMain" Orientation="Vertical" PreviewKeyDown="spMain_PreviewKeyDown">
        <Label Content="Some good movies:"/>
        <StackPanel Orientation="Horizontal" Margin="10" PreviewKeyDown="spLawrence_PreviewKeyDown">
            <Label Content="Lawrence of Arabia" FontWeight="Bold"/>
            <Label Content="David Lean"/>
            <Button Content="Like" Padding="8,0"/>
            <TextBox Width="75" Margin="5,2" PreviewKeyDown="tbLawrence_PreviewKeyDown"/>
        </StackPanel>
    </StackPanel>
</Window>

Filed under Events Tagged with , , ,

#584 – Handling an Event That Has Already Been Handled

June 20, 2012 1 Comment

When a routed event in WPF is being routed up or down the hierarchy of elements, an element that handles a particular event can choose to optionally mark the event as handled, by setting the KeyEventArgs.Handled property to true.  Normally, this short-circuits the routing of the event and elements further up (or down) the tree will not see the event.

But you can choose to override this default behavior, setting up an event handler that will get called even when the underlying event has been handled.

You can ask to by notified of handled events by adding an event in code, rather than declaring it in XAML.  The third parameter indicates that this handler should be called even when the event has already been marked as handled.

        public MainWindow()
        {
            this.InitializeComponent();

            spMain.AddHandler(UIElement.KeyDownEvent, (KeyEventHandler)spMain_KeyDown, true);
        }

Filed under Events Tagged with , , ,

#583 – Interrupting the Routing Process

June 19, 2012 1 Comment

We saw that a routed event in WPF can be routed up or down the logical and visual trees, being seen by any element in the hierarchy that chooses to handle the event.

In the diagram below, a KeyDown event is routed up the tree.

Any of the event handlers that intercept this event can choose to indicate that they have handled the event, by setting the Handled property of the KeyEventArgs argument to true.  When this happens, the event will not continue propagating up (or down) the tree.

        private void tbLawrence_KeyDown(object sender, KeyEventArgs e)
        {
            DumpInfo("tbLawrence_KeyDown", sender, e.Source);
        }

        private void spLawrence_KeyDown(object sender, KeyEventArgs e)
        {
            DumpInfo("spLawrence_KeyDown", sender, e.Source);
            e.Handled = true;    // The event stops here
        }

        private void spMain_KeyDown(object sender, KeyEventArgs e)
        {
            DumpInfo("spMain_KeyDown", sender, e.Source);
        }

        private void winMain_KeyDown(object sender, KeyEventArgs e)
        {
            DumpInfo("winMain_KeyDown", sender, e.Source);
        }

Filed under Events Tagged with , , ,

#582 – Events Are Routed Even When a Handler is Not Defined

June 18, 2012 Leave a comment

When a routed event is fired and the event travels up (bubbles) or down (tunnels) the logical and visual trees, corresponding event handlers will fire for any controls that have defined an event handler that matches the event.

However, whether or not you have handlers defined, the event will continue to travel up (or down) the tree, looking for controls that have handlers defined.  In the example below, a KeyDown event in the TextBox fires an event in the TextBox and then in the main Window.

<Window
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:Microsoft_Windows_Themes="clr-namespace:Microsoft.Windows.Themes;assembly=PresentationFramework.Aero"
    xmlns:loc="clr-namespace:WpfApplication11"
    xmlns:sys="clr-namespace:System;assembly=mscorlib"
    xmlns:d="http://schemas.microsoft.com/expression/blend/2008" xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
    x:Class="WpfApplication11.MainWindow"
	x:Name="Window" Title="Routed Events" Width="400"
    KeyDown="winMain_KeyDown">

    <StackPanel Orientation="Vertical">
        <Label Content="Some good movies:"/>
        <StackPanel Orientation="Horizontal" Margin="10" >
            <Label Content="Lawrence of Arabia" FontWeight="Bold"/>
            <Label Content="David Lean"/>
            <Button Content="Like" Padding="8,0"/>
            <TextBox Width="75" Margin="5,2" KeyDown="tbLawrence_KeyDown"/>
        </StackPanel>
        <StackPanel Orientation="Horizontal" Margin="10">
            <Label Content="Schindler's List" FontWeight="Bold"/>
            <Label Content="Steven Spielberg"/>
            <Button Content="Like" Padding="8,0"/>
        </StackPanel>
    </StackPanel>
</Window>

Filed under Events Tagged with , , ,

← Older posts