Het veld dat geen tekst meer aannam

U bereidt een les voor. De ride bevalt u niet, dus klikt u op „Ride leegmaken” om opnieuw te beginnen. RideComposer vraagt u te bevestigen, en u bevestigt. Daarna wilt u de soort les kiezen: de lijst gaat niet open. U klikt in een veld om een naam te typen: er verschijnt niets.

Het programma lijkt niet vastgelopen: uw klikken komen aan. Maar het toetsenbord niet.

En na een herstart werkt alles weer.

We kwamen deze fout zelf tegen, bij het voorbereiden van lessen, gedurende enkele dagen, zonder hem op commando te kunnen oproepen.

Waarom hij zo moeilijk te vangen was

Een fout die „soms” optreedt, is de ergste soort: je weet niet waar je moet kijken. En deze nam telkens een andere vorm aan.

Op 2 oktober was het de naam van de ride: je kon de cursor plaatsen en wissen, maar niet typen. Naar een andere weergave gaan en terugkeren volstond om alles te herstellen.

Op 6 oktober was het de tempofilter van de bibliotheek: geen cursor, geen invoer; alleen de kleine pijltjes van het veld werkten. „In sommige mappen wel, in andere niet”, noteerden we toen. Na een herstart was er niets meer van te zien.

Eerst zochten we in het programma zelf, en controleerden we de meest overtuigende verklaringen een voor een. Een onzichtbaar element boven de velden? Geen enkel, in geen van de 326 mappen van de geteste bibliotheek. Een sneltoets die de cijfers onderschept? Geen. Een verband met de gekozen map? Ook niet: de fout verdween na een herstart, in dezelfde map.

Geen van deze controles heeft iets opgelost. Maar ze hebben voorkomen dat we een correctie voor de verkeerde oorzaak publiceerden, een die leek te werken tot de volgende keer.

Waar we naar moesten kijken: de stap ervoor

Het spoor kwam van een eenvoudige vraag: wat deed u vlak voordat het vastliep?

Op de avond van 6 oktober kwam de fout twee keer na elkaar terug, telkens na dezelfde handeling: „Ride leegmaken”, daarna de lijst met de soort les. Deze keer konden we het programma bekijken op het moment zelf van de blokkering, zonder het te herstarten.

Wat we zagen: voor Windows was het venster van RideComposer actief. Maar de pagina erin dacht van niet; ze beschouwde zichzelf niet langer als „op de voorgrond”. En een pagina die denkt niet op de voorgrond te staan, opent haar lijsten niet en neemt geen getypte tekst aan.

De boosdoener zat dus niet in de ride, en ook niet in de bibliotheek. Het was het kleine bevestigingsvenster van Windows, dat vraagt „weet u het zeker?”. Bij het sluiten gaf het het venster terug aan RideComposer, maar niet het toetsenbord aan de pagina.

We denken dat de voorvallen van 2 en 6 oktober dezelfde oorsprong hadden, maar dat kunnen we achteraf niet bewijzen: niemand had de handeling genoteerd die eraan voorafging.

De correctie, en het bewijs

De oplossing beslaat een paar regels: telkens wanneer een van deze vensters sluit, vraagt RideComposer Windows nu uitdrukkelijk om de controle terug te geven. Het venster antwoordt precies zoals vroeger; u merkt geen verschil, behalve dat het toetsenbord werkt.

Met „lijkt te werken” wilden we ons niet tevredenstellen. Dus hebben we de echte fout nagebootst, met een echt Windows-venster, gesloten met de Enter-toets, en echte toetsaanslagen:

• vóór de correctie: je typt „67” in het veld, en het blijft leeg;
• na de correctie: je typt „67”, en het verschijnt.

Als een veld niet reageert

Het is niet de eerste keer dat ons een veld wordt gemeld dat „niet meer werkt”. In september leek de naam van de ride niet bewerkbaar. Dat was hij wel, maar zijn cursor, zonder kader of achtergrond, was op de vetgedrukte titel gewoon niet te zien. Hetzelfde symptoom, een totaal andere oorzaak.

Overkomt het u, dan besparen twee gegevens ons dagen: wat u vlak ervoor deed, en wat u ziet wanneer u klikt: een knipperende cursor, of niets. Precies dat heeft ons bij deze fout gebracht.

De correctie zit in RideComposer sinds versie 2.0.16. De huidige versie, 2.0.18, kunt u downloaden op ridecomposer.com.