Tien uur foutzoeken in AccountView

Tien uur foutzoeken in AccountView: hoe we de PDF-viewer weer stabiel kregen

Soms is softwareonderhoud overzichtelijk en voorspelbaar. En soms bestaat het uit tien uur zoeken in Visual FoxPro, oude ActiveX-componenten, tijdelijke DBF-bestanden, onleesbare gecompileerde code, verborgen viewers en crashende PDF-componenten, in een koppig transportmanagementsysteem dat zijn geheimen niet zomaar prijsgeeft.

Gisteren was zo’n tweede dag.

We besteedden bijna een hele werkdag aan een ernstig stabiliteitsprobleem in TransportMaster TMS binnen AccountView. De symptomen waren duidelijk. Na enkele tientallen pdf-documenten doorbladeren liep AccountView vast in eindeloze verwerking. Tijdelijke FoxPro-bestanden stapelden zich op en de interne toestand leek onstabiel. Op het dieptepunt startte AccountView niet eens meer goed en meldde het ontbrekende interne objecten en beschadigde klassedefinities. De omgeving was praktisch onbruikbaar.

De eerste noodoplossing was pijnlijk eenvoudig: bestanden in de tijdelijke gebruikersmap verwijderen en opnieuw proberen. AccountView startte dan weer, maar een echte oplossing is dat niet. Het is alsof de stroom van een heel gebouw wordt uitgeschakeld omdat één lichtschakelaar kuren heeft. Handig in een noodgeval, maar geen procedure die in de ondersteuningsdocumentatie thuishoort.

Het probleem

De oorzaak zat in de oude PDF-weergave binnen AccountView. Het oorspronkelijke, verborgen weergaveonderdeel was nog aanwezig en gebruikte oudere componenten zoals PDFVIEW.OCX en HiQPdf.rda. Die draaiden binnen Visual FoxPro, waar de zeggenschap over vensters, COM-callbacks, timers, tijdelijke bestanden, vastzetbare panelen en de levenscyclus van ActiveX-componenten allemaal meetellen.

Alleen de zichtbare viewer vervangen was niet genoeg. De oude werd achter de schermen nog aangemaakt, kreeg nog bestandspaden door, veranderde nog van formaat en bleef deelnemen aan de levenscyclus van het formulier. Daardoor kon deze AccountView nog steeds ontregelen. Dat was de cruciale ontdekking: de nieuwe viewer verving de oude niet, maar was een extra component op het formulier. De oorspronkelijke AccountView-viewer was verborgen, maar nog actief.

Dat verklaarde het vreemde gedrag: de nieuwe viewer kon stabiel zijn terwijl de oude, onzichtbare viewer de sessie alsnog ontregelde. Alsof de voordeur werd gerepareerd terwijl de achterdeur open bleef staan.

Het onderzoek

De sessie begon met een fout in AccountViews omzetting van PDF naar TIFF:

PROCEDURE PDF_MANAGER.WRITE_PDF_AS_TIFF Error number: 1429 Cannot set the operation command. Cannot write. Error 0xE8.

Eerst vermoedden we dat de vervangende HiQPdf-stub onvolledig was. We voegden logging toe om te zien of AccountView functies of commando’s aanriep die de stub nog niet ondersteunde. Daarna vervingen en testten we de PDF-viewer. Even leek alles stabiel, tot AccountView na voldoende documenten doorbladeren weer vastliep.

We onderzochten de tijdelijke FoxPro-mappen, geladen procedures, AccountView-invoegcode en de nieuwe FoxDocViewer-koppeling. Steeds duidelijker werd dat het geen afzonderlijke fout was, maar een kettingreactie:

• De oude PDF-viewer was nog actief en kon boven op de nieuwe liggen.
• De oude viewer werd nog door AccountView-code bestuurd en van formaat veranderd.
• De nieuwe viewer had striktere grenzen en bescherming van de levenscyclus binnen het FoxPro-formulier nodig.
• Fouten bij formaatwijzigingen, vastzetten, documentnavigatie of ontbrekende bestanden konden doorwerken in de interne toestand van AccountView.
• Tijdelijke FoxPro-tabellen en indexen deden de symptomen op databasebeschadiging lijken, ook wanneer de eerste oorzaak in de levenscyclus van de viewer zat.

Meerdere keren dachten we dat het systeem stabiel was. Meerdere keren bewees AccountView meteen het tegendeel. Een ogenschijnlijk “opgeloste” applicatie liep even later opnieuw vast. Op een ander moment startte deze niet meer en verscheen:

Object TMS_LIC is not found.

Dat is niet de motiverende boodschap waarop u na uren foutzoeken hoopt. Maar ze wees wel naar het echte probleem: de opstart- en invoegregistratie van AccountView was onstabiel geworden. Na herstel en herindexering van de relevante interne registratie- en systeemtabellen startte AccountView weer. Dat was het eerste grote keerpunt.

De daadwerkelijke oplossing

De uiteindelijke oplossing was geen magische regel code. We moesten de hele overgang tussen AccountView, FoxPro, de oude viewer en de nieuwe viewer robuuster maken.

De belangrijkste wijzigingen waren:

• Het gevaarlijke gedrag van de oude PDF-viewer uitschakelen terwijl genoeg van de interface bleef bestaan om AccountView deze veilig te laten aanmaken.
• Een stabiele PDFVIEW.OCX-stub maken die de oude COM-identiteit behoudt zonder de instabiele viewer te laden.
• Een stabiele HiQPdf.rda-stub maken die een behoudend antwoord geeft en stdin uitleest, zodat AccountView niet vastloopt op communicatie met het hulpproces.
• De FoxPro-koppeling met de viewer robuuster maken zodat formaatwijzigingen, vastzetten, sluiten, ontbrekende bestanden en herhaald wisselen van document de applicatie niet ontregelen.
• De nieuwe FoxDocViewer op de juiste plek zetten zodat deze de scheidingsbalken, sluitknoppen en bediening voor vastzetten van AccountView niet meer bedekt.
• Padomzetting voor tests verwijderen zodat de klantinstallatie de echte paden uit de documenttabel van AccountView gebruikt.
• De definitieve broncode opschonen en verpakken in twee zelfstandig bouwbare Visual Studio-oplossingen voor onderhoud op lange termijn.

Om dezelfde reden maakten we ook FileDropArea, een verwante ActiveX-component, robuuster. Een component die in een eigen venster goed werkt, kan binnen AccountView nog steeds problemen geven. Ingebouwde ActiveX-componenten moeten uiterst voorspelbaar zijn: geen onverwachte modale vensters, onbeschermde COM-callbacks, riskante aannames bij slepen en neerzetten, fouten bij formaatwijzigingen of verrassingen in de levenscyclus.

Het resultaat

Na de laatste aanpassingen is uitgebreid getest op Windows 11 Pro: met meerdere vensters, vastgezette en losgemaakte PDF-panelen, herhaald bladeren, ontbrekende documenten, echte PDF-paden, formaatwijzigingen en gewone TransportMaster-werkprocessen.

Het resultaat: uiterst stabiel.

Geen eindeloze verwerking, geen explosie van tijdelijke bestanden, geen verborgen viewer die om de bovenste laag vecht, geen opstartfouten en geen willekeurig gedrag dat na het doorbladeren van records op beschadiging lijkt. De nieuwe FoxDocViewer toonde documenten correct en bleef tijdens de stresstests stabiel.

Na ongeveer tien uur foutzoeken, testen, laten mislukken, repareren, opnieuw laten mislukken, herindexeren en compileren, en af en toe twijfelen aan alle levenskeuzes rond oude COM-componenten, hadden we een stabiele oplossing en nette broncodepakketten.

Wat we hebben geleerd

De grootste les is dat koppelingen met oudere software niet alleen draaien om het zichtbare onderdeel vervangen. In een framework als AccountView blijven verborgen componenten, oude COM-identiteiten, formuliergebeurtenissen, paneelbeheerders, timers en tijdelijke FoxPro-tabellen soms nog actief lang nadat u denkt iets te hebben vervangen.

Als een oude component nog is geregistreerd, wordt aangemaakt en formaat- of navigatieaanroepen ontvangt, hoort deze dus nog bij het systeem. Ook als niemand hem voor het overleg heeft uitgenodigd.

We leerden ook dat Visual FoxPro-applicaties tegelijk opmerkelijk veerkrachtig en bijzonder onverbiddelijk kunnen zijn. Eén verkeerde aanname aan de COM-grens kan op een databaseprobleem lijken. Eén verborgen viewer kan de indruk wekken dat de nieuwe defect is. Eén modaal venster of onbeschermde callback kan een verder correcte koppeling ontregelen.

De eindstand

Het werk is nu uitgewerkt tot bruikbaar overdrachtsmateriaal:

• Een opgeschoonde, bouwbare HiQPdf.rda -stuboplossing.
• Een opgeschoonde, bouwbare PDFVIEW.OCX -stuboplossing.
• Een robuuste FoxDocViewer-koppeling voor AccountView.
• Een robuuste FileDropArea ActiveX-component, voorbereid op toekomstige inbouw.
• Een heldere uitleg van de oorzaken van het oude gedrag en waarom de nieuwe aanpak veiliger is.

Het was een sessie waarin ieder antwoord twee nieuwe vragen opriep en op elk “dit moet het zijn” vijf minuten later volgde: “nee, wacht, hij loopt nog steeds vast.” Maar uiteindelijk is het systeem stabiel, zijn de oorzaken geïsoleerd en zijn de componenten veel beter opgewassen tegen de AccountView-omgeving.

Geen slecht resultaat voor een vrijdag die begon met een PDF-viewer en uitliep op een expeditie door oude COM-techniek, Visual FoxPro, de binnenkant van AccountView en de grenzen van wat koffie kan oplossen.