locked
How prevent KeyDown event originating from a TextBox in a third party control from bubbling up to containing app

    Question

  • Hello,

    We have a Windows Store control library in which we implement a control that can be hosted in Windows Store apps.

    During the lifetime of this control it might create dynamically a TextBox control. What is happening is when we type text into the TextBox, the KeyDown event is fired by the TextBox and it is propagated up the controls hierarchy reaching a KeyDown event handler in the hosting app's MainPage.

    What I am looking for is a way to prevent bubbling up of the KeyDown/Up events when my TextBox is the originator of these events.

    I tried subclassing TextBox with MyTextBox and overriding OnKeyDown() setting e->Handled = true there to prevent the KeyDown event from bubbling up. I also tried handling the KeyDown event in a delegate and setting e->Handled = true there as well. Both these methods did in fact prevent the bubbling up of the event but they also prevented the text in the TextBox from being updated. 

    Is there a way to have the TextBox behave normally when text is typed into it (updating its content...) while prevent the KeyDown/Up event from bubbling up all the way and being handled by any present KeyDown/Up handlers that know nothing about the originator of this event? If not, does this mean that a developer that is hosting our control, when handling a KeyDown/Up event, say on a MainPage in the app, has to always check the e->OriginalSource and only perform some action when they know what OriginalSource is, as opposed to when OriginalSource could be from deep inside the third party control?

    Thanks

    Roger

    Thursday, April 11, 2013 4:35 PM

Answers

  •  If not, does this mean that a developer that is hosting our control, when handling a KeyDown/Up event, say on a MainPage in the app, has to always check the e->OriginalSource and only perform some action when they know what OriginalSource is, as opposed to when OriginalSource could be from deep inside the third party control?

     

    Well, if a developer is handling keyboard events at that high of a level they would need/want to determine where the event came from anyway, IMHO. I've used 3rd party controls that did not propagate events and had to work around the loss of control over not having notification of those events.
    • Proposed as answer by Jesse Jiang Wednesday, April 17, 2013 2:01 AM
    • Marked as answer by Jesse Jiang Thursday, April 18, 2013 2:17 AM
    Thursday, April 11, 2013 5:59 PM

All replies

  •  If not, does this mean that a developer that is hosting our control, when handling a KeyDown/Up event, say on a MainPage in the app, has to always check the e->OriginalSource and only perform some action when they know what OriginalSource is, as opposed to when OriginalSource could be from deep inside the third party control?

     

    Well, if a developer is handling keyboard events at that high of a level they would need/want to determine where the event came from anyway, IMHO. I've used 3rd party controls that did not propagate events and had to work around the loss of control over not having notification of those events.
    • Proposed as answer by Jesse Jiang Wednesday, April 17, 2013 2:01 AM
    • Marked as answer by Jesse Jiang Thursday, April 18, 2013 2:17 AM
    Thursday, April 11, 2013 5:59 PM
  • Thanks l3v316 and Jesse
    Thursday, April 18, 2013 2:06 PM
  • If you set in the keydown event textbox key.handled then it wont pass on.


    n.Wright

    Thursday, April 18, 2013 8:28 PM
  • That is correct, however it not only wont pass on to higher controls in the hierarchy but also it will prevent the TextBox of performing the internal handling and updating its text, which is not what I was looking for in my case.
    Friday, April 19, 2013 1:06 AM
  • That is correct, however it not only wont pass on to higher controls in the hierarchy but also it will prevent the TextBox of performing the internal handling and updating its text, which is not what I was looking for in my case.

    On the keydown event in the textbox you could add something like.

    if (key.handled==false)

    key.handled=true;

    It looks like you need a post keydown event to trap out any keys missed by the textbox.


    n.Wright


    Friday, April 19, 2013 1:11 AM
  • That is what I had tried. Wont work.
    Friday, April 19, 2013 4:04 AM