wpf textbox won't throw textInput event

Question

I have a window with a textbox that is not throwing textInput events when typing.

I have been looking at it with Snooper. Only the KeyDown and KeyUp events get thrown.

It IS responding to a few keys: Space, backspace, Insert, home, delete, end

It responds to copy & paste commands, as well as Select All

It is NOT responding to any character, symbol or number

And here's the kicker: This window is opened via a shared method that is called from two different places in the code. When called from one location the textbox works perfectly, when called from other location it doesn't.

I have ruled out binding, data converters, styles, control location. I stripped the window down to just a single plain textbox with no bindings, and the problem persists.

I've tried all I can think of to track down this mysterious bug. I can't see what could be handling my event before the previewTextInput even gets throw, or why it could possibly be only occurring half the time.

Any ideas about the cause of this bug, or other tools I could try to trace the events would be greatly appreciated!

Edit: Adding some code to demonstrate. This has been stripped down to the barest code required, and the issue is still occurring.

<Window x:Class="EventViewEmail"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    Width="880" Height="600">

    <TextBox VerticalAlignment="Top"/>
</Window>

notice the lack of bindings, styles, or anything else that may be interfering the control

Public Class EventViewEmail
    'all code removed from the view-behind'
End Class   

this is the static class that builds the window. The two separate calls to this class build the arguments differently. I've removed the code that uses the arguments to show that they aren't affecting the issue at hand.

Public Class EventManager
    Public Shared Sub Show(e As EventEdit, p As WorkplanPageViewModel)
        Dim w = New EventViewEmail
        If w Is Nothing Then Return

        'removed datacontext for testing'
        'w.DataContext = e '
        'w.Tag = p'
        w.Show()
    End Sub
End Class

The only other thing I can add is that the code calling the Show() sub are coming from two separate solutions. Not sure what impact that could possibly have after I've removed all the arguments

Edit 2: I have been trying to trace the events sequence to narrow down where the event is getting handled. So far I can see that between the keyDown and keyUp events, there is a sequence of events that should be happening that isn't:

• PreviewInputReport / InputReport (no source)
• PreviewTextInputStart / TextInputStart (textbox)
• PreviewTextInput / TextInput (textbox)
• PreviewInputReport / InputReport (textboxView)

the keydown event isn't being handled, so I'm not sure why the PreviewInputReport is not getting fired

Answer 1

Disclaimer

I'll post C# code because I'm not fluent enough in VB to write code (only to read it in a limited scope). I'll try to translate it if I find some time, or anyone of you can feel free to do it.

---

I have managed to reproduce the behavior you described by handling the PreviewTextInput event up the visual tree on the window (remember it's a tunneling routed event):

<Window (...)>
    <StackPanel>
        <TextBox x:Name="myTextBox"></TextBox>
    </StackPanel>
</Window>

public partial class MainWindow
{
    public MainWindow()
    {
        InitializeComponent();
        PreviewTextInput += (s, e) => e.Handled = true;
    }
}

So in my opinion it's a strong suspect for the cause of your problems. It also explains the comment to @AQuirky's answer that your PreviewTextInput handler is not called. You can confirm that that's the case by subscribing differently (the handler is called even if the event was marked as handled):

public partial class MainWindow
{
    public MainWindow()
    {
        InitializeComponent();
        PreviewTextInput += (s, e) => e.Handled = true;
        myTextBox.AddHandler(
            routedEvent: PreviewTextInputEvent,
            handler: new TextCompositionEventHandler((s, e) =>
            {
                if (e.Handled)
                    throw new Exception("Gotcha!");
            }),
            handledEventsToo: true);
    }
}

If this turns out to be correct diagnosis, then there's one thing that's somewhat mysterious - who and where does handle the PreviewTextInput event? I guess that's for you to investigate...

This comment from @l33t might come in handy:

Look for global event handlers like EventManager.RegisterClassHandler(typeof(TextBox), UIElement.PreviewTextInputEvent, ...) and/or behaviors. Are you using any third-party UI library? Look in their code as well.

---

Update

Since it seems like PreviewTextInput is not the culprit after all, here's what I'd do next.

If I'm not mistaken, there's a whole chain of events being fired prior to TextInputEvent, and I believe handling any of those can break the chain. It also looks like InputManager is responsible for managing this event cycle (you can inspect its C# source code here).

That being said I suggest doing the following:

1. Using InputManager.Current subscribe to its PreProcessInput and/or PostProcessInput events (optionally also PreNotifyInput and PostNotifyInput)
2. Record the events chain in the working scenario (especially inspect the args' StagingItem.Input.RoutedEvent, which holds the routed event currently being processed)
3. Repeat the procedure for the not working scenario
4. Pinpoint the first difference - the first routed event being processed in the working scenario, but not being processed in the not working scenario
5. Investigate both last common routed event and the first one that's different - perhaps one of those is handled in your code?

Answer 2

In this case it turned out that the form that launched the window in the not working case was a winform. The winform was blocking the keystrokes. This was fixed by opening the window as a modal.

Answer 3

I had the same problem here. The difference between the two calls was: one time the WPF-Windows was called modal (works) and one time nonmodal (doesnt work), everytime from a WindowsForms Window.

As Shaboboo wrote in his anwer, this is the difference, but what, if you need to call nonmodal. The answer is given this thread. (stupid me, I had the same problem 2 years ago, asked and got an answer). We have to use

ElementHost.EnableModelessKeyboardInterop(wpfWindow);

Thanks again to V.Leon

Answer 4

The problem is that while the TextInput is being fired (not thrown...exceptions are thrown) you are not seeing it because the text box itself is using it. To catch this event you need to use the PreviewTextInput. So for example

    <TextBox TextInput="UIElement_OnTextInput" PreviewTextInput="UIElement_OnPreviewTextInput"></TextBox>

With event handlers...

    private void UIElement_OnTextInput(object sender, TextCompositionEventArgs e)
    {
        Console.WriteLine($"In text input event, {e.Text}");
    }

    private void UIElement_OnPreviewTextInput(object sender, TextCompositionEventArgs e)
    {
        Console.WriteLine($"In preview text input event, {e.Text}");
    }

The first handler is never called, the second one always.

Answer 5

Your handler is not called because other handlers have marked the event as handled. You can add an handler with AddHandler() and pass true for the third argument:

public MainWindow()
{
    var handler = new RoutedEventHandler(OnTextInput);
    myTextBox.AddHandler(TextInputEvent, handler, handledEventsToo: true);
}

private static void OnTextInput(object sender, RoutedEventArgs e)
{
}