El campo que ya no escribía

Está preparando una clase. El ride no le convence, así que hace clic en «Vaciar el ride» para empezar de cero. RideComposer le pide que confirme, y usted confirma. Luego quiere elegir el tipo de clase: la lista no se abre. Hace clic en un campo para escribir un nombre: no aparece nada.

El programa no parece colgado: los clics llegan. Pero el teclado, no.

Y después de reiniciar, todo vuelve a funcionar.

Nos encontramos con este fallo nosotros mismos, preparando clases, durante varios días, sin conseguir reproducirlo a voluntad.

Por qué era tan difícil de atrapar

Un fallo que ocurre «a veces» es el peor de todos: no se sabe dónde mirar. Y este cambiaba de forma.

El 2 de octubre fue el nombre del ride: se podía colocar el cursor y borrar, pero no escribir. Pasar a otra vista y volver bastaba para arreglarlo todo.

El 6 de octubre fue el filtro de tempo de la biblioteca: sin cursor, sin escritura; solo funcionaban las pequeñas flechas del campo. «En algunas carpetas sí, en otras no», anotamos entonces. Tras reiniciar, nada.

Primero buscamos dentro del propio programa y comprobamos una a una las explicaciones que parecían más sólidas. ¿Un elemento invisible colocado encima de los campos? Ninguno, en ninguna de las 326 carpetas de la biblioteca probada. ¿Un atajo de teclado que capturara las cifras? Ninguno. ¿Alguna relación con la carpeta elegida? Tampoco: el fallo desaparecía al reiniciar, en la misma carpeta.

Ninguna de estas comprobaciones corrigió nada. Pero evitaron que publicáramos una corrección para una causa falsa, que habría parecido funcionar hasta la siguiente vez.

Lo que había que mirar: el paso anterior

La pista llegó con una pregunta sencilla: ¿qué hizo justo antes de que se bloqueara?

La noche del 6 de octubre, el fallo volvió dos veces seguidas, siempre después del mismo gesto: «Vaciar el ride» y luego la lista del tipo de clase. Esta vez pudimos observar el programa en el momento exacto del bloqueo, sin reiniciarlo.

Lo que vimos: para Windows, la ventana de RideComposer estaba activa. Pero la página que contenía creía que no lo estaba: ya no se consideraba «en primer plano». Y una página que cree no estar en primer plano no abre sus listas ni acepta el texto que se escribe.

El culpable no estaba, por tanto, en el ride ni en la biblioteca. Era el pequeño cuadro de confirmación de Windows, el que pregunta «¿está seguro?». Al cerrarse, devolvía la ventana a RideComposer, pero no el teclado a la página.

Creemos que los episodios del 2 y del 6 de octubre tenían el mismo origen, pero no podemos demostrarlo a posteriori: nadie había anotado el gesto que los precedió.

La corrección, y la prueba

El remedio cabe en unas pocas líneas: cada vez que uno de estos cuadros se cierra, RideComposer pide ahora expresamente a Windows que le devuelva el control. El cuadro sigue respondiendo exactamente igual que antes; usted no nota ninguna diferencia, salvo que el teclado funciona.

No queríamos conformarnos con un «parece que va». Así que reprodujimos el fallo real, con un cuadro real de Windows, cerrado con la tecla Intro, y pulsaciones reales de teclado:

• antes de la corrección: se escribe «67» en el campo y sigue vacío;
• después de la corrección: se escribe «67» y aparece.

Si un campo no responde

No es la primera vez que nos señalan un campo que «ya no funciona». En septiembre, el nombre del ride parecía no poder editarse. Sí se podía, pero su cursor, sin borde ni fondo, simplemente no se veía sobre el título en negrita. Mismo síntoma, causa sin ninguna relación.

Si le ocurre, dos datos nos ahorran días: lo que hizo justo antes y lo que ve en el momento de hacer clic: un cursor que parpadea, o nada. Es exactamente lo que permitió encontrar este.

La corrección está en RideComposer desde la versión 2.0.16. La versión actual, la 2.0.18, se puede descargar en ridecomposer.com.