Почему PreviewTextInput не обрабатывает пробелы?

Question

Я обрабатываю событие PreviewTextInput в моем окне, чтобы обработать считывания с устройства чтения магнитных карт.Я обрабатываю событие в окне, так что не имеет значения, на каком отдельном элементе управления находится фокус.

После того, как обработчик определил, что смахивание началось (вводится символ «%» или «;»), он обрабатывает все события до тех пор, пока смахивание не будет завершено.Эта система, как правило, работает довольно хорошо, с несколькими важными исключениями:

Когда символ пробела (и, возможно, символ \ n) вводится из считывателя, они не обрабатываются PreviewTextInput, но отправляются непосредственно во что угодноконтроль сфокусирован.Как ни странно, обработчик получает \ r символов.Это вызывает нежелательное поведение.

То, что я хочу, - это способ всех ключевых событий на уровне окна и возможность обрабатывать их, если я хочу.Я попробовал PreviewKeyDown и нашел его немного громоздким для использования и для получения значений char.PreviewTextInput намного приятнее, потому что я могу просто прочитать свойство Text.

Существует ли причина, по которой PreviewTextInput не обрабатывает определенные символы?Есть ли сопоставимый метод для получения всех событий, включая пробелы?

Answer 1

Я нашел какое-то объяснение в этом вопросе на форуме WPF :

Поскольку некоторые IME рассматривают нажатие клавиш в пробелах как часть процесса составления текста, поэтому оно съедаетАвалон, чтобы сообщить правильный составной текст через событие TextInput.

И еще немного информации из документации MSDN о событии TextInput :

..Для ввода с клавиатуры WPF сначала отправляет соответствующие события KeyDown / KeyUp.Если эти события не обрабатываются и клавиша является текстовой (а не управляющей клавишей, такой как стрелки направления или функциональные клавиши), то возникает событие TextInput.Между событиями KeyDown / KeyUp и TextInput не всегда существует простое сопоставление «один к одному», поскольку несколько нажатий клавиш могут генерировать один символ ввода текста, а одиночные нажатия клавиш могут генерировать многосимвольные строки.Это особенно верно для таких языков, как китайский, японский и корейский, которые используют редакторы методов ввода (IME) для генерации тысяч возможных символов в соответствующих алфавитах.

Когда WPF отправляет событие KeyUp / KeyDown, Keyустанавливается в Key.System, если нажатия клавиш могут стать частью события TextInput (например, при нажатии ALT + S).Это позволяет коду в обработчике событий KeyDown проверять наличие Key.System и, если он найден, оставлять обработку для обработчика последующего вызванного события TextInput.В этих случаях различные свойства аргумента TextCompositionEventArgs могут использоваться для определения исходных нажатий клавиш.Точно так же, если IME активен, Key имеет значение Key.ImeProcessed, а ImeProcessedKey дает исходное нажатие клавиши или нажатия клавиши.

Кстати, вот два связанных вопроса:

• Как запретить элементам управления вводом красть символ пробела из TextCompositionManager?
• Справка по событиям WPF TextCompositionManager

Answer 2

Я нашел один обходной путь - подключить PreviewKeyDown вместо PreviewTextInput. К сожалению, этот подход требует гораздо большего количества обходных путей, чтобы получить конкретный символ для той кнопки, которую они нажали. Самый надежный способ, который я нашел, был в этом вопросе. Это кажется довольно обременительным для того, что, по моему мнению, должно быть довольно простым. У кого-нибудь есть лучший способ сделать это?