Een tien uur durende debugsessie in AccountView

Een tien uur durende debugging sessie binnen AccountView: Hoe we de PDF-kijkers weer stabiel hebben gemaakt

Soms is software onderhoud een schoon, voorspelbaar werk. En soms is het tien uur kijken naar Visual FoxPro, legacy ActiveX controles, tijdelijke DBF-bestanden, gemengde samengestelde code, verborgen kijkers, crashende PDF-componenten, en een zeer koppig transportmanagement systeem dat zichzelf weigert te verklaren.

Gisteren was het tweede soort.

We hebben bijna een hele werkdag doorgebracht met het onderzoeken van een ernstig stabiliteitsprobleem in TransportMaster TMS die binnen loopt AccountViewDe symptomen waren niet subtiel. Na het bladeren door een paar dozijn PDF-documenten, zou AccountView uit de hand gaan. Tijdelijke FoxPro-bestanden zouden ophopen. De interne staat leek onstabiel te worden. In de ergste momenten zou AccountView niet meer correct beginnen en fouten zoals ontbrekende interne objecten en beschadigde klassendefinities rapporteren.

De eerste oplossing was pijnlijk eenvoudig: verwijder de bestanden in de gebruikers temporary directory en probeer opnieuw. Dat maakte AccountView opnieuw starten, maar natuurlijk is dat geen oplossing. Dat is het digitale equivalent van het uitschakelen van de gebouw stroom en weer aan omdat een licht schakelaar wordt achtervolgd. Nuttig in een noodsituatie, niet precies iets dat je wilt documenteren als een ondersteuningsprocedure.

Het probleem

De wortel van het probleem was de oude PDF-bekijkpijplein binnen AccountView. AccountView bevatte nog steeds zijn oorspronkelijke verborgen PDF-bekijkers, gebaseerd op oude componenten zoals PDFVIEW.OCX en HiQPdf.rda. Deze componenten werden gebruikt in een Visual FoxPro-hostomgeving waar vensterbezit, COM-oproepen, timers, temporele bestanden, dockingpanelen en ActiveX-levencyclusgedrag van belang zijn.

Het vervangen van de zichtbare kijker alleen was niet voldoende. De oude kijker werd nog steeds achter de schermen gecreëerd, nog steeds paden ontvangen, nog steeds vergroot, nog steeds deelnemen aan de vorm levenscyclus, en nog steeds in staat om AccountView te destabiliseren. Dat was de belangrijke ontdekking: de nieuwe kijker was geen vervanging voor de oude. Het was een extra plugin geplaatst op het formulier. De oorspronkelijke AccountView PDF-kicker was verborgen, maar nog steeds levend.

Dat verklaarde het vreemde gedrag: de nieuwe kijker kon stabiel zijn, maar de oude verborgen kijker kon de sessie nog steeds verstoren.

De slag om defect te herstellen

De sessie begon met een fout in AccountViews PDF-to-TIFF pad:

PROCEDURE PDF_MANAGER.WRITE_PDF_AS_TIFF Foutenummer: 1429 Kan het besturingsbevel niet instellen. Kan niet schrijven. Fouten 0xE8.

Aanvankelijk was de verdenking dat de HiQPdf stub onvolledig was. Logging werd toegevoegd zodat we konden zien of AccountView oproept naar functies of commandopaden die onze stub nog niet heeft geïmplementeerd.

We inspecteerden vervolgens de FoxPro temp directories, de geladen procedure stack, de AccountView add-in code en de nieuwe FoxDocViewer integratie. Hoe meer we keken, hoe duidelijker het werd dat dit niet één enkele bug was. Het was een ketenreactie:

• De oude PDF-kicker was nog actief en kon bovenop de nieuwe kicker zitten.
• De oude kijker werd nog steeds vergroot en gecontroleerd door AccountView code.
• De nieuwe kijker had strenger grenzen en levenscyclusbescherming nodig in een FoxPro-formulier.
• Fouten bij het vergroten, docken, documentnavigatie of ontbrekende bestanden kunnen in cascade worden gevormd tot AccountView-statsproblemen.
• Voorlopige FoxPro tabellen en indexen maakten de symptomen lijken op databasecorruptie, zelfs wanneer de eerste trigger de levenscyclus van de kijker was.

We dachten meerdere malen dat het systeem stabiel was. Meerdere malen AccountView bewees het onmiddellijk anders. Op een gegeven moment leek de toepassing fixed te zijn, slechts om een paar minuten later uit de controle te draaien. Op een ander moment begon het niet meer en toonde:

Object TMS_LIC is niet gevonden.

Dat was niet precies de motiverende boodschap die men hoopte na uren van debugging. Maar het wijst ons naar het echte probleem: AccountView's start- en add-in-registratie staat was onstabiel geworden. Nadat we de relevante interne registratie / systeemtabelen hebben gerepareerd en opnieuw geïndexeerd, is AccountView opnieuw gestart. Dat was het eerste grote keerpunt.

De werkelijke oplossing

De uiteindelijke oplossing was niet één magische lijn. Het was een verhardende pas over de hele grens tussen AccountView, FoxPro, de oude kijker, en de nieuwe kijker.

De belangrijkste veranderingen waren:

• Het gevaarlijke gedrag van de oude PDF-kicker uitgeschakeld Terwijl er nog genoeg van zijn interface intact blijft zodat AccountView het veilig kan instantiëren.
• Een stabiel PDFVIEW.OCX-stub gemaakt de oude COM-identiteit behoudt, maar vermijdt het laden van de onstabiele legacy-toeschouwer.
• Een stabiele HiQPdf.rda stub gecreëerd Dat geeft een conservatieve reactie en draait stdin uit zodat AccountView de communicatie met de helperproces niet blokkeert.
• Versterkt de FoxPro-zijde-toeschouwer-integratie Dus vergroten, docken, sluiten, ontbrekende bestanden en herhaalde documentwijzigingen destabiliseren de host niet.
• Verplaatst de nieuwe FoxDocViewer in de juiste visuele positie Dus het dekt niet meer AccountView splitters, sluiten knoppen, of docking controles.
• Verwijderde padkaarting alleen voor de test Dus de cliëntinstallatie gebruikt de werkelijke paden die zijn opgeslagen in AccountViews documenttabel.
• Reiniging en verpakking van de eindbron In twee standalone bouwbare Visual Studio-oplossingen voor langdurig onderhoud.

We hebben ook een verwante ActiveX-controle, het FileDropArea-component, gehardeerd om dezelfde reden. Een controle die zich goed gedraagt in zijn eigen venster kan nog steeds gevaarlijk zijn binnen AccountView. Gashte ActiveX-componenten moeten extreem conservatief zijn: geen onverwachte modal dialogen, geen onbewaakte COM-oproepen, geen onveilige sleep-/drop-aanvattingen, geen grootte-uitzonderingen en geen levenscyclusverrassingen.

Het resultaat

Na de laatste correcties werd het systeem zwaar getest op Windows 11 Pro met meerdere Windows, aangekoppelde en ongekoppelde PDF-kijkpanelen, herhaaldelijk door documenten scrollen, ontbrekende documenten, echte PDF-paden, groottewijzigingen en normale TransportMaster-werkstromen.

Het resultaat: Stevig als een rots..

Geen spinning. Geen temp-file explosie. Geen verborgen kijkers vechten voor de bovenste laag. Geen AccountView start falen. Geen willekeurig corruptie-achtig gedrag na het door scrollen door records. De nieuwe FoxDocViewer toonde de documenten correct en bleef stabiel door de stress tests.

Na ongeveer tien uur debugging, testen, breken, repareren, opnieuw breken, opnieuw indexeren, recompileren en af en toe alle levenskeuzes met betrekking tot legacy COM-controles ondervragen, eindigden we met een stabiele oplossing en schone bronpakketten.

Wat wij hebben geleerd

In een kader als AccountView, verborgen besturingen, oude COM-identiteiten, vorm levenscyclushooks, docking managers, timers en FoxPro templates kunnen allemaal lang blijven deelnemen nadat je denkt dat je iets hebt vervangen.

Met andere woorden: als een oud onderdeel nog steeds geregistreerd is, nog steeds instantieert en nog steeds omvang- of navigatieoproepen ontvangt, is het nog steeds onderdeel van het systeem, zelfs als niemand het op de bijeenkomst heeft uitgenodigd.

We hebben ook geleerd dat Visual FoxPro-toepassingen indrukwekkend veerkrachtig en diep onvergeeflijk tegelijkertijd kunnen zijn. Een verkeerde veronderstelling op de COM-grens kan lijken op een databaseprobleem.

Eindelijke staat

Het werk is nu opgeruimd tot een goed technisch materiaal:

• Een schone bouwbare HiQPdf.rda stoofoplossing.
• Een schone bouwbare PDFVIEW.OCX stoofoplossing.
• Een geharde FoxDocViewer-integratie voor AccountView.
• Een geharde FileDropArea ActiveX bediening die is voorbereid voor toekomstige inbouw.
• Een duidelijke verklaring waarom het oorspronkelijke gedrag mislukte en waarom de nieuwe aanpak veiliger is.

Het was een van die sessies waar elk antwoord twee nieuwe vragen creëerde, en elke dit moet het zijn werd vijf minuten later gevolgd door nee, wacht, het draait nog steeds. Maar uiteindelijk werd het systeem gestabiliseerd, de oorzaken werden geïsoleerd, en de laatste componenten zijn nu veel beter geschikt om te overleven binnen het AccountView-raamwerk.

Niet slecht voor een vrijdag debugging sessie die begon met een PDF-kijkers en kortom veranderde in een volledige expeditie door middel van legacy COM, Visual FoxPro, AccountView interne, en de emotionele grenzen van koffie.