O campo que parou de aceitar texto

Você está preparando uma aula. O ride não está bom, então você clica em “Esvaziar o ride” para começar do zero. O RideComposer pede para você confirmar, e você confirma. Em seguida, quer escolher o tipo de aula: a lista não abre. Você clica em um campo para digitar um nome: nada aparece.

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

E depois de reiniciar, tudo volta a funcionar.

Nós mesmos encontramos esse defeito, preparando aulas, durante vários dias, sem conseguir reproduzi-lo quando queríamos.

Por que era tão difícil de pegar

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

Em 2 de outubro, foi o nome do ride: dava para posicionar o cursor e apagar, mas não digitar. Passar para outra tela e voltar bastava para resolver tudo.

Em 6 de outubro, foi o filtro de tempo da biblioteca: sem cursor, sem digitação; só as setinhas do campo funcionavam. “Em algumas pastas sim, em outras não”, anotamos na época. Depois de reiniciar, nada.

Primeiro procuramos dentro do próprio programa, verificando uma por 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 capturando os números? Nenhum. Alguma relação com a pasta escolhida? Também não: o defeito sumia ao reiniciar, na mesma pasta.

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

O que era preciso olhar: o passo anterior

A pista veio de uma pergunta simples: o que você fez logo antes de travar?

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, conseguimos observar o programa no exato momento do travamento, sem reiniciá-lo.

O que vimos: para o Windows, a janela do RideComposer estava ativa. Mas a página dentro dela achava que não: já não se considerava “em primeiro plano”. E uma página que acha que não está em primeiro plano não abre suas listas nem aceita o texto digitado.

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

Acreditamos que os episódios de 2 e de 6 de outubro tinham a mesma origem, mas não conseguimos provar isso depois do fato: ninguém tinha anotado o gesto que veio antes deles.

A correção, e a prova

O remédio cabe em poucas linhas: toda vez que uma dessas caixas se fecha, o RideComposer agora pede explicitamente ao Windows que lhe devolva o controle. A caixa continua respondendo exatamente como antes; você não percebe diferença nenhuma, a não ser que o teclado funciona.

Não quisemos nos contentar com um “parece que funciona”. Então reproduzimos o defeito real, com uma caixa de verdade do Windows, fechada com a tecla Enter, e teclas digitadas de verdade:

• antes da correção: digita-se “67” no campo, e ele continua vazio;
• depois da correção: digita-se “67”, e aparece.

Se um campo não responder

Não é a primeira vez que nos relatam um campo que “parou de funcionar”. Em setembro, o nome do ride parecia não ser editável. Era, mas o cursor, sem borda nem fundo, simplesmente não aparecia sobre o título em negrito. O mesmo sintoma, uma causa sem nenhuma relação.

Se acontecer com você, duas informações nos poupam dias: o que você fez logo antes e o que você vê na hora do clique: um cursor piscando, 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 baixada em ridecomposer.com.