locked
WinJS Flyout - how can I detect where the user clicked? RRS feed

  • Question

  • A flyout is displayed and when a user clicks somewhere outside the flyout, it is hidden. How can I detect which element they clicked on before the flyout was hidden?
    Wednesday, April 10, 2013 12:17 AM

All replies

  • Might be easier to answer with the reason why you would like to do that, to maybe give a better solution. But the i don't think you can know what the element that was clicked on as far as i am aware. 

    Also might be worth pointing out that not just clicking on the app somewhere will close the flyout, things like displaying of some UI elements like search will, resizing the app, or scrolling etc.


    • Edited by Andy Ardener Wednesday, April 10, 2013 7:21 AM added some extra info
    Wednesday, April 10, 2013 7:01 AM
  • Hello, Andy

    Thank you for your reply.

    My app presents the user with a series of questions (answered by multiple choice radios, checkboxes etc.). They can choose to swipe past a question if they don't feel like answering it right now. When they swipe without answering, a flyout appears warning them that they have not answered and the swipe is 'suspended'. The flyout contains a button labelled 'answer now'. If they click that button, the flyout remains suspended and they can answer the question and then swipe again to reveal the next question.

    I assume that when they swipe without answering, they really do intend to skip the question, so if they click/tap somewhere while the flyout is displayed, the flyout is dismissed and the suspended swipe continues, revealing the next question.

    It occurred to me that while the flyout is displayed, the user might not click the 'answer now' button, but, rather, decide to click on a radio button, checkbox or whatever in order to answer the question. That, of course, has the effect of dismissing the flyout, whereupon the suspended swipe is resumed and the next question is displayed.

    I think I may have solved the problem (I still need to test it). I was attempting to get some info about the source of the click/tap event from somewhere like the beforehide or afterhide events of the flyout. The way I detect a swipe is to handle the MSPointerDown and MSPointerUp events, calculatingin the handler of the MSDown event the distance and the time between the two and thus determining whether it's a swipe and in what direction. I think I can inspect the event in the MSPointerDown handler, see if event.srcElement has an id, and, if it does, use that to dtermine whether a user clicked/tapped a checkbox or whatever.

    Wednesday, April 10, 2013 1:29 PM
  • Ah, no. It looks like I haven't solved it. The MSPointerUp event fires before the flyout's afterhide event, but, strangely, its event information doesn't contain any srcElement.id when it fires while the flyout is displayed. As long as the flyout is not displayed I can get at the srcElement.id of the MSPointerUp event, but that's not much use.
    Wednesday, April 10, 2013 2:12 PM
  • I guess I can't get srcElement.id in the MSPointerUp event because the element I click on doesn't get the focus. For example, say the flyout is currently displayed and I click on a radio button. That dismisses the flyout but doesn't actually focus the radio button, which I suppose means that it's not in fact the source of the event. This seems to be confirmed by my trying in the same scenario to find the document.activeElement, which in fact just returns the document body. The flyout seems to eat all the information I might possibly find useful.
    Wednesday, April 10, 2013 4:18 PM