38

Does it matter whether I create event handlers for PointerPressed, Click, or Tapped?IOW, is there any functional difference between the following:

<Button x:Name="BackButton" PointerPressed="BackButton_Click"/>    
<Button x:Name="BackButton" Click="BackButton_Click"/>    
<Button x:Name="BackButton" Tapped="BackButton_Click"/>

?

Shimmy Weitzhandler
  • 101,809
  • 122
  • 424
  • 632
B. Clay Shannon-B. Crow Raven
  • 8,547
  • 144
  • 472
  • 862
  • 2
    An important differences between Click and Tapped, is that Click will get fired if the control Manipulation event fired, but tapped will not, as an example, if you drag a button to move it, the button will move and on manipulation Completed, the button click will get fired but tapped will not, tapped is only fired on TAP without dragging. – Sameh Jul 22 '15 at 14:14
  • 1
    Another difference I've noticed when used with Buttons, is that key events Enter and Space, are routed to Clicked handler, but not to Tapped. Enter and Space won't even be handled by KeyUp/KeyDown handlers by default! – Shahin Dohan Mar 28 '18 at 12:43

4 Answers4

58

Click is there for backwards compatibility, and is essentially the same as Tapped. Tapped is a "high level gesture" that will translate automatically to a click, tap, pen press, etc. and is what I would recommend to use.

PointerPressed is not what you want. Here's why: if I press and hold, the PointerPressed event will fire when I initially "press" and then a PointerReleased will fire once it's done. This is more low-level and you can make decisions about how long it was pressed, etc. Typically a long press is NOT what you want to consider a "Click" or a "Tap" because by definition Tap is shorter duration. Therefore, for what you want, "Tap" conveys it best because it translates the gesture for you using the system timing for what is considered a "Tap" vs. a hold and automatically promotes clicks and pen presses to the same event. PointerPressed will fire whenever a button is pressed or a finger is pressed regardless of how long the interaction lasts.

I have a fairly involved app that demonstrates the various interactions that you can download from http://windows8applications.codeplex.com - just refer to the Chapter 4 sample called "Touch."

Jeremy Likness
  • 7,531
  • 1
  • 23
  • 25
  • 8
    I like to think of it as: 1. Tapped is the new Click 2. PointerPressed is the new MouseDown 3. PointerReleased is the new MouseUp – Flatliner DOA Sep 08 '13 at 12:00
  • 3
    Based on the problems described in [this thread](http://stackoverflow.com/questions/21820482/winrt-xaml-tapped-event-responds-slowly-while-clicked-responds-rapidly/21842945?noredirect=1#comment34723798_21842945) I'd suggest that `Click` might be there for more than just backcompat. – Filip Skakun Apr 01 '14 at 06:04
  • Why can't I get `PointerPressed` to work in UWP? It only gets fired on Right-Click. When I Left-Click then button, nothing happens. – Shimmy Weitzhandler Oct 20 '18 at 21:23
  • 2
    No. Not quite so. `Click` is not there for backwards compatibility as @jeremy-likness said. It is far from the equiv to `Tapped`. If this is a `Button` control, you should handle `Click` every single time and ignore `Tapped`. If you are handling touch gestures for a special use case, then `Tapped` becomes very important. To repeat myself, `Tapped` is NOT the new `Click` as @flatliner-doa said. `Click` (on a `Button` control) has not changed. – Jerry Nixon Oct 07 '19 at 18:53
27

Jeremy's answer isn't entirely accurate. In another thread someone reported having a problem with taps not working the same way as clicks when clicking/tapping in rapid succession and it is easy to reproduce with the code below and could easily be extended to pointer events.

public sealed partial class MainPage : Page
{
    private int clicks = 0;
    private int taps = 0;
    public MainPage()
    {
        this.InitializeComponent();
        var button = new Button();
        button.Width = 500;
        button.Height = 200;
        button.Content = string.Format("Clicks: {0}, Taps: {1}", clicks, taps);
        button.Click += (s, e) => button.Content = string.Format("Clicks: {0}, Taps: {1}", ++clicks, taps);
        button.Tapped += (s, e) => button.Content = string.Format("Clicks: {0}, Taps: {1}", clicks, ++taps);
        this.Content = button;
    }
}

Click is what you should handle on a regular button. It has the logic that is expected of a button. Among the things I can think of are

  • it works with a keyboard as well as with a mouse
  • it works even if you press the button and release it slowly
  • it can be canceled when you press by dragging away from the button and also resumed by dragging back to it after previously pressing the button
  • it is limited to a single button at a time, so if you try to click two buttons together - the first one touched won't click (different than on the original Surface/PixelSense, which supports multi-user interactions!)
  • it likely works better with things like automation and as such with accessibility features of Windows
  • it always works

As demonstrated in the sample code - the Tapped event doesn't register for all taps if you tap repeatedly. I'm not sure if this is because some underlying gesture recognition logic sees some double taps or simply rejects every other tap for whatever other reason. It works for quick single touch/pen taps or mouse clicks, but is a generic event that you can handle on any UIElement and might be used if you want to distinguish between taps, double taps, right taps (!) or holds on arbitrary UI elements.

The pointer events are lower level and you can use them to handle slightly more advanced interactions not already built into the framework. As I mentioned - a click consists of a press and accompanying release both occurring on the button, so a similar interaction could be modeled with pointer events. You could, for example, use it to implement some sort of a Whac-A-Mole/Twister combination type of game where you'd want to mash many UI elements at the same time which you couldn't do with clicks.

Community
  • 1
  • 1
Filip Skakun
  • 31,624
  • 6
  • 74
  • 100
  • 2
    Yes, Click is not there for backwards compatibility. Click is there because it is a Button. Tapped is there because there could be a touch gesture you want to handle. The fact that Button forwards Tapped to Click is a favor to the developer. It is FAR from identical. – Jerry Nixon Oct 07 '19 at 18:51
7

You should use Click for Buttons (and ListView, Hyperlink, MenuFlyoutItem, ContentDialog, etc). Tapped is just a pointer event, so it doesn’t get invoked if you use a keyboard, or access key, or automation.

Ben Schoepke
  • 789
  • 2
  • 7
  • 17
3

I know this is an old subject but the winning answer is not correct when it says that Click and Tapped are essentially the same. They are not. If you need some rapid clickin' in a control, Tapped does not respond in the same speed as Click does.

In very specific scenarios, like in a custom made numeric keypad, if the user wants to input a value like '11' (tapping the same button twice), when you use Tapped, you often miss the second char, so you get a '1', instead a '11'. With Click that doesn't happen.

ps.: I'm using UWP