2011-11-01 18 views
16

Estoy manejando el evento PreviewTextInput en mi ventana para manejar golpes desde un lector de tarjeta magnética. Manejo el evento en la ventana, de modo que no importa qué control individual esté enfocado.¿Por qué PreviewTextInput no maneja espacios?

Una vez que el controlador determina que se ha iniciado un deslizamiento (se ingresa un carácter '%' o ';'), maneja todos los eventos hasta que finaliza el deslizamiento. Este sistema generalmente funciona bastante bien, con algunas excepciones importantes:

Cuando un carácter de espacio (y posiblemente un carácter \ n) son ingresados ​​por el lector, no son manejados por PreviewTextInput, sino que se envían directamente a cualquier control enfocado Por extraño que parezca, el controlador recibe \ r caracteres. Esto causa un comportamiento no deseado.

Lo que quiero es una forma de capturar todos los eventos clave en el nivel de la ventana, y tengo la oportunidad de manejarlos si quiero. He intentado PreviewKeyDown y me pareció un poco engorroso de usar, y para obtener valores de char. PreviewTextInput es mucho mejor porque simplemente puedo leer la propiedad Text.

¿Hay algún motivo por el que PreviewTextInput no maneje ciertos caracteres? ¿Hay algún método comparable para obtener todos los eventos, incluidos los espacios?

Respuesta

10

me encontré con algún tipo de explicación en this WPF forum question:

Debido a que algunos IME tratarán a golpe de teclado espacios en blanco como parte del proceso de composición de texto, es por eso que se come por Avalon reportar el texto compuesta correcta a través de eventos TextInput.

Y algo más de información de la MSDN documentation of the TextInput event:

... Para la entrada de teclado, WPF envía en primer lugar los eventos apropiados KeyDown/KeyUp. Si esos eventos no se manejan y la clave es textual (en lugar de una tecla de control como flechas direccionales o teclas de función), se genera un evento TextInput. No siempre hay un mapeo uno a uno simple entre los eventos KeyDown/KeyUp y TextInput porque varias pulsaciones de teclas pueden generar un solo carácter de entrada de texto y las pulsaciones de teclas individuales pueden generar cadenas de caracteres múltiples. Esto es especialmente cierto para los idiomas como el chino, el japonés y el coreano que utilizan los editores de métodos de entrada (IME) para generar los miles de caracteres posibles en sus alfabetos correspondientes.

Cuando WPF envía un evento KeyUp/KeyDown, Key se establece en Key.System si las teclas pueden formar parte de un evento TextInput (si se presiona ALT + S, por ejemplo). Esto permite que el código en un controlador de eventos KeyDown compruebe Key.System y, si se encuentra, deja el procesamiento para el controlador del evento TextInput que se generó posteriormente. En estos casos, las diversas propiedades del argumento TextCompositionEventArgs se pueden usar para determinar las pulsaciones de teclas originales. De forma similar, si un IME está activo, Key tiene el valor de Key.ImeProcessed, e ImeProcessedKey da el toque de teclado o las pulsaciones de teclas originales.

Por cierto, aquí hay dos preguntas relacionadas:

3

Una solución que he encontrado es conectar PreviewKeyDown en lugar de PreviewTextInput. Desafortunadamente, ese enfoque requiere mucho más contorneo para obtener un char concreto para el botón que presionaron. La forma más confiable que encontré estaba en this question.. Me parece bastante engorroso por lo que creo que debería ser bastante simple. Alguien tiene una mejor manera de hacer esto?

+0

sí, eso es lo mismo que terminé usando – 00jt

Cuestiones relacionadas