java - Problemas de JTextField con Numpad
linux redhat (5)
Recientemente me he encontrado con un extraño problema con el JTextField de Java. Cuando ejecuto el siguiente código (ver más abajo), al escribir un "0" en el campo de texto, primero se envía una acción de pegado y luego se escribe "0". Por ejemplo, si se copia "texto" en el portapapeles, se escribe "texto0" cuando escribo "0". Del mismo modo, al escribir un "4" se reemplaza el carácter anterior por un "4" (supongo que esto es una acción de eliminación, luego se escribe el "4"). Escribir "7" borra el campo de texto antes de escribir "7".
Aquí está el código:
import javax.swing.JFrame;
import javax.swing.JTextField;
public class Main {
public static void main(String[] args) {
JFrame frame = new JFrame();
JTextField text = new JTextField();
frame.add(text);
frame.setSize(500, 500);
frame.setVisible(true);
}
}
El problema está ocurriendo en Red Hat Linux (accedido usando VNC desde Windows XP); Todo funciona como se espera en Windows XP.
Actualización : Tampoco hay problemas con el programa en Ubuntu. También he intentado usar diferentes teclados y visores VNC.
Actualización 2 : Versiones de Java
Para Red Hat:
java version "1.6.0_17"
OpenJDK Runtime Environment (IcedTea6 1.7.7) (rhel-1.17.b17.el5-x86_64)
OpenJDK 64-Bit Server VM (build 14.0-b16, mixed mode)
Para XP:
java version "1.7.0_05"
Java(TM) SE Runtime Environment (build 1.7.0_05-b05)
Java HotSpot(TM) Client VM (build 23.1-b03, mixed mode, sharing)
Actualización 3 : Intenté ejecutar el programa en tres máquinas diferentes de Red Hat (todas en el mismo grupo en el trabajo), y además intentó ejecutarlo desde una computadora XP diferente y reiniciarlo.
Actualización 4 : Hoy llegué al trabajo para encontrar que el problema había desaparecido mágicamente. Sin embargo, sería bueno saber por qué sucedió en primer lugar para que yo (y cualquier otra persona que se encuentre con este extraño problema) sepa cómo solucionarlo en el futuro.
Bueno, es difícil dar una respuesta precisa de por qué, pero en realidad no es un fenómeno extraño. Por lo general, cuando se realiza una compartición de VNC o escritorio remoto, los eventos de teclado y mouse de una máquina se transmiten a otra máquina. Cuando se realiza este mapeo, puede haber una posibilidad justa de que pueda haber un comportamiento erróneo, especialmente con la copia del portapapeles, pegar. Ocurre no solo en el mundo de Linux sino también en el mundo de Windows.
Lo cuento por experiencia propia. En mi lugar de trabajo a menudo ingresamos a otras máquinas, algunas ejecutan XP y otras ejecutan Windows 7. La acción de copiar el portapapeles en una máquina y pegar en una máquina remota funciona en algunos sistemas y falla en otros.
Citando otra experiencia similar con java y acceso a escritorio remoto, tengo una aplicación java que se ejecuta en mi eclipse. Cuando entro en mi máquina desde algunas de las otras máquinas, encuentro que eclipse es completamente incapaz de iniciar la aplicación. Para que funcione, primero tengo que iniciarlo en mi propio sistema, mantener la aplicación en ejecución y luego rdc de otro en el mío.
Solo para imaginar, si este es el caso de Windows XP y Windows 7, que son conocidos pertenecen a la misma familia. Solo se puede esperar que algo así de raro no pueda ocurrir cuando se usan Linux y Windows junto con VNC :)
Como se dijo, es difícil ser demasiado exacto acerca de por qué está sucediendo, pero se puede decir con seguridad que esto es algo que sucede simplemente a nivel de SO a nivel de SO y no a nivel de marco de swing.
Esto parece ser un problema conocido con VNC. Según el sitio web oficial de VNC:
La tecla Bloq Num puede estar desincronizada. Desconecte, presione la tecla Bloq Num del equipo cliente una vez y luego vuelva a conectarse.
Fuente: http://www.realvnc.com/products/viewerplus/known-issues/
Esto también aparece en las preguntas frecuentes de VNC:
P. ¡El teclado no funciona / las teclas hacen cosas extrañas!
Hay un problema común que puede causar esto. Si se presiona una tecla modificadora, como Shift, Ctrl o Alt, y la ventana del visor pierde el foco o muere, el mensaje de ''liberación de tecla'' nunca llega al espectador y, por lo tanto, nunca llega al servidor remoto. La máquina remota pensará entonces que M es Ctrl-M, etc. Hemos hecho varias cosas para reducir la posibilidad de que esto suceda; los espectadores liberan varios modificadores automáticamente cuando pierden el enfoque, por ejemplo, pero todavía puede ocurrir y puede ser confuso cuando lo hace. La solución es fácil: simplemente presione y suelte la tecla modificadora que está bloqueada. Si no sabes cuál es, entonces pruébalos uno a la vez.
Fuente: http://www-hep.nhn.ou.edu/d0/software/vnc-3.3.2r2/faq.html
Si esta información es indicativa de su problema, puede ser que cuando el problema "desapareció mágicamente", el Num Pad simplemente estaba sincronizado con VNC ese día y no sincronizado con los demás (lo que por supuesto significa que el problema podría surgen de nuevo).
Intenta poner este código al inicio de tu programa.
KeyboardFocusManager.setCurrentKeyboardFocusManager(new DefaultKeyboardFocusManager(){
public boolean dispatchKeyEvent(KeyEvent e) {
if (e.getKeyLocation() == KeyEvent.KEY_LOCATION_NUMPAD){
return true;
}
return super.dispatchKeyEvent(e);
}
});
No estoy seguro, pero solo estoy respondiendo en un intento de ayudar:
Mi experiencia con IcedTea es mala. No puedo recordar exactamente lo que sucedió, pero en ese entonces, la instalación del JRE oficial de Java resolvió mis problemas. Id est: el JRE proporcionado por Oracle.
Verifique las funciones de "Deshabilitar el modo de teclado de la aplicación" en Terminal,