O campo que deixou de escrever

Está a preparar uma aula. O ride não o convence, por isso clica em «Esvaziar o ride» para recomeçar do zero. O RideComposer pede-lhe que confirme, e confirma. A seguir quer escolher o tipo de aula: a lista não abre. Clica num campo para escrever um nome: não aparece nada.

O programa não parece bloqueado: os cliques chegam. Mas o teclado não.

E depois de reiniciar, tudo volta a funcionar.

Encontrámos este defeito nós próprios, ao preparar aulas, durante vários dias, sem conseguir reproduzi-lo quando queríamos.

Porque era tão difícil de apanhar

Um defeito que acontece «às vezes» é o pior de todos: não se sabe para onde olhar. E este mudava de forma.

A 2 de outubro, foi o nome do ride: podia-se pôr o cursor e apagar, mas não escrever. Passar para outra vista e voltar bastava para repor tudo.

A 6 de outubro, foi o filtro de tempo da biblioteca: sem cursor, sem escrita; só as pequenas setas do campo funcionavam. «Nalgumas pastas sim, noutras não», anotámos na altura. Depois de reiniciar, nada.

Começámos por procurar no próprio programa, verificando uma a uma as explicações que pareciam mais sólidas. Um elemento invisível por cima dos campos? Nenhum, em nenhuma das 326 pastas da biblioteca testada. Um atalho de teclado que capturasse os algarismos? Nenhum. Uma relação com a pasta escolhida? Também não: o defeito desaparecia ao reiniciar, na mesma pasta.

Nenhuma destas verificações corrigiu fosse o que fosse. Mas evitaram que publicássemos uma correção para uma causa errada, que teria parecido funcionar até à vez seguinte.

O que era preciso olhar: o gesto anterior

A pista veio de uma pergunta simples: o que fez imediatamente antes de bloquear?

Na noite de 6 de outubro, o defeito voltou duas vezes seguidas, sempre depois do mesmo gesto: «Esvaziar o ride» e, depois, a lista do tipo de aula. Desta vez, pudemos observar o programa no próprio momento do bloqueio, sem o reiniciar.

O que vimos: para o Windows, a janela do RideComposer estava ativa. Mas a página lá dentro julgava que não: já não se considerava «em primeiro plano». E uma página que julga não estar em primeiro plano não abre as suas listas nem aceita o texto escrito.

O culpado não estava, portanto, no ride nem na biblioteca. Era a pequena caixa de confirmação do Windows, a que pergunta «tem a certeza?». Ao fechar-se, devolvia a janela ao RideComposer, mas não o teclado à página.

Pensamos que os episódios de 2 e de 6 de outubro tinham a mesma origem, mas não o podemos provar depois do facto: ninguém tinha anotado o gesto que os precedeu.

A correção, e a prova

O remédio cabe em poucas linhas: sempre que uma destas caixas se fecha, o RideComposer pede agora explicitamente ao Windows que lhe devolva o controlo. A caixa continua a responder exatamente como antes; não nota diferença nenhuma, a não ser que o teclado funciona.

Não nos quisemos contentar com um «parece que funciona». Reproduzimos por isso o defeito real, com uma verdadeira caixa do Windows, fechada com a tecla Enter, e teclas realmente premidas:

• antes da correção: escreve-se «67» no campo, e ele fica vazio;
• depois da correção: escreve-se «67», e aparece.

Se um campo não responder

Não é a primeira vez que nos assinalam um campo que «deixou de funcionar». Em setembro, o nome do ride parecia não ser editável. Era, mas o cursor, sem moldura nem fundo, simplesmente não se via sobre o título a negrito. O mesmo sintoma, uma causa sem qualquer relação.

Se lhe acontecer, duas informações poupam-nos dias: o que fez imediatamente antes e o que vê no momento em que clica: um cursor a piscar, ou nada. Foi exatamente isso que permitiu encontrar este.

A correção está no RideComposer desde a versão 2.0.16. A versão atual, a 2.0.18, pode ser descarregada em ridecomposer.com.