locked
Pointer Location

    Question

  • I've got an application that has a control that responds to the 'PointerOver' visual state.  When the pointer is over the object, it is supposed to turn red (this is a simplified example).  I've got all the pointer events handled (enter, exit, pressed, etc.) and my control turns red when you move the mouse over it, but if my application starts up and the mouse happens to be over the control, it doesn't reflect the proper visual state.  I get no events telling me the mouse has moved because it hasn't, but I still need to display a state that shows the mouse is over the new control.  How do you get the current state of the pointer device(s) when the mouse hasn't moved?  (this is a simplified example, I have a drag-and-drop example that also has the same problem.  Once you've dropped the item, the mouse doesn't move and now there's a new control underneath the mouse that needs to reflect the current state of the mouse).

    Tuesday, May 27, 2014 3:28 PM

Answers

  • You get the pointerId from pointer events: the pointerId isn't definitively set until there is a pointer event. If there is a mouse it will usually be pointerId 1, but that isn't contractual and cannot be safely depended on.

    The normal practice is to ignore an inactive pointer and trigger when you do get the pointer events. When the user switches to the app a PointerEntered event will fire when (if) the mouse moves. You can see this behavior with all of the in-box controls

    Moving a control under a pointer doesn't move the pointer and so doesn't trigger a pointer event. If you already have a pointerId for the pointer you are interested in you can do your own hit testing.

    --Rob

    Wednesday, May 28, 2014 10:16 PM
    Owner

All replies

  • You can use the static PointerPoint.GetCurrentPoint to get an existing PointerPoint. Once you have the PointerPoint you can query its Position property.

    The trick is that until you've received pointer messages you can't know for sure which pointers the user is going to use or what their ID is. Typically you would not worry about this until the user triggered a pointer message: apps generally shouldn'ttrigger mouse behavior if the user is using touch or vice versa.

    --Rob

    Tuesday, May 27, 2014 5:20 PM
    Owner
  • Yes, I've found the PointerPoint.GetCurrentPoint method, but it requires an integer argument (uint pointerId).  From where are we supposed to get the 'pointerId'?

    Regarding the original question, how are we supposed to handle situations like a drag-and-drop operation where after you've released the mouse button (or lifted your finger, whichever), a new window appears beneath your pointer device?  If you move your pointer over a control, you get the event triggers, but what happens when the reverse is true (that is, you move a window underneath the pointer).

    • Edited by DRAirey1 Tuesday, May 27, 2014 5:31 PM
    Tuesday, May 27, 2014 5:28 PM
  • You get the pointerId from pointer events: the pointerId isn't definitively set until there is a pointer event. If there is a mouse it will usually be pointerId 1, but that isn't contractual and cannot be safely depended on.

    The normal practice is to ignore an inactive pointer and trigger when you do get the pointer events. When the user switches to the app a PointerEntered event will fire when (if) the mouse moves. You can see this behavior with all of the in-box controls

    Moving a control under a pointer doesn't move the pointer and so doesn't trigger a pointer event. If you already have a pointerId for the pointer you are interested in you can do your own hit testing.

    --Rob

    Wednesday, May 28, 2014 10:16 PM
    Owner
  • This is a design flaw.  I can think of numerous examples where navigation will leave the mouse over a control that needs to respond to the MouseOver event.  The Standard Tiles application that is part of the Windows Store templates is one of them.  If you click on a tile and navigate to a page that also contains times, your mouse will end up on top of a tile.  It doesn't display the proper mouse over status until the user moves the mouse.
    Monday, June 09, 2014 10:17 AM