Il campo che non scriveva più

State preparando una lezione. Il ride non vi convince, quindi cliccate su «Svuota il ride» per ricominciare da zero. RideComposer vi chiede di confermare, e confermate. Poi volete scegliere il tipo di lezione: l'elenco non si apre. Cliccate in un campo per scrivere un nome: non compare nulla.

Il programma non sembra bloccato: i clic arrivano. Ma la tastiera no.

E dopo un riavvio, tutto torna a funzionare.

Abbiamo incontrato questo difetto noi stessi, preparando lezioni, per diversi giorni, senza riuscire a riprodurlo a comando.

Perché era così difficile da individuare

Un difetto che si presenta «a volte» è il peggiore: non si sa dove guardare. E questo cambiava forma.

Il 2 ottobre era il nome del ride: si poteva posizionare il cursore e cancellare, ma non scrivere. Passare a un'altra vista e tornare indietro bastava a sistemare tutto.

Il 6 ottobre era il filtro del tempo nella libreria: niente cursore, niente digitazione; funzionavano solo le piccole frecce del campo. «In alcune cartelle sì, in altre no», avevamo annotato allora. Dopo un riavvio, più niente.

Per prima cosa abbiamo cercato all'interno del programma, verificando una per una le spiegazioni che sembravano più solide. Un elemento invisibile sopra i campi? Nessuno, in nessuna delle 326 cartelle della libreria provata. Una scorciatoia da tastiera che catturasse le cifre? Nessuna. Un legame con la cartella scelta? Nemmeno: il difetto spariva al riavvio, nella stessa cartella.

Nessuna di queste verifiche ha corretto qualcosa. Ma ci hanno evitato di pubblicare una correzione per la causa sbagliata, che sarebbe sembrata funzionare fino alla volta successiva.

Cosa bisognava guardare: il gesto precedente

La pista è arrivata da una domanda semplice: che cosa avete fatto subito prima del blocco?

La sera del 6 ottobre il difetto si è ripresentato due volte di seguito, sempre dopo lo stesso gesto: «Svuota il ride», poi l'elenco del tipo di lezione. Questa volta abbiamo potuto osservare il programma nel momento stesso del blocco, senza riavviarlo.

Ecco cosa abbiamo visto: per Windows, la finestra di RideComposer era attiva. Ma la pagina al suo interno credeva di non esserlo: non si considerava più «in primo piano». E una pagina che crede di non essere in primo piano non apre i suoi elenchi e non accetta il testo digitato.

Il colpevole quindi non era nel ride, né nella libreria. Era la piccola finestra di conferma di Windows, quella che chiede «siete sicuri?». Chiudendosi, restituiva la finestra a RideComposer, ma non la tastiera alla pagina.

Pensiamo che gli episodi del 2 e del 6 ottobre avessero la stessa origine, ma non possiamo dimostrarlo a posteriori: nessuno aveva annotato il gesto che li aveva preceduti.

La correzione, e la prova

Il rimedio sta in poche righe: ogni volta che una di queste finestre si chiude, RideComposer chiede ora esplicitamente a Windows di restituirgli il controllo. La finestra risponde esattamente come prima; non notate alcuna differenza, se non che la tastiera funziona.

Non volevamo accontentarci di un «sembra andare». Abbiamo quindi riprodotto il difetto reale, con una vera finestra di Windows, chiusa con il tasto Invio, e veri tasti premuti:

• prima della correzione: si digita «67» nel campo, e resta vuoto;
• dopo la correzione: si digita «67», e compare.

Se un campo non risponde

Non è la prima volta che ci viene segnalato un campo che «non funziona più». A settembre, il nome del ride sembrava non modificabile. Lo era, ma il suo cursore, senza bordo né sfondo, semplicemente non si vedeva sul titolo in grassetto. Stesso sintomo, causa del tutto diversa.

Se vi capita, due informazioni ci fanno risparmiare giorni: che cosa avete fatto subito prima e che cosa vedete nel momento in cui cliccate, un cursore che lampeggia oppure niente. È esattamente ciò che ha permesso di trovare questo.

La correzione è in RideComposer dalla versione 2.0.16. La versione attuale, la 2.0.18, si scarica da ridecomposer.com.