Zehn Stunden Fehlersuche in AccountView

Eine 10-Stunden-Debugging-Sitzung im Inneren AccountView: Wie wir den PDF-Schauer wieder stabil gemacht haben

Manchmal ist Software-Wartung ein sauberer, vorhersehbarer Job. Und manchmal sind es zehn Stunden, in Visual FoxPro, ältere ActiveX-Steuerungen, vorübergehende DBF-Dateien, gemischte Kompilierte Code, versteckte Zuschauer, abstürzende PDF-Komponenten und ein sehr hartnäckiges Transportmanagementsystem zu blicken, das sich nicht erklären will.

Gestern war die zweite Art.

Wir haben fast einen ganzen Arbeitstag damit verbracht, ein schweres Stabilitätsproblem in TransportMaster TMS, der innerhalb von AccountView läuft. Die Symptome waren nicht subtil. Nach dem Durchsuchen ein paar Dutzend PDF-Dokumenten würde AccountView aus der Kontrolle geraten. Vorübergehende FoxPro-Dateien würden sich stapeln. Der interne Zustand schien instabil zu werden. In den schlimmsten Momenten würde AccountView nicht mehr richtig starten und Fehler wie fehlende interne Objekte und beschädigte Klassendefinitionen melden.

Die erste Lösung war schmerzhaft einfach: Löschen Sie die Dateien im Benutzer-Temp-Verzeichnis und versuchen Sie es erneut. Das hat AccountView erneut gestartet, aber natürlich ist das keine Lösung. Das ist das digitale Äquivalent des Aus- und Rückschaltens des Gebäudes, weil ein Lichtschalter verfolgt wird. Nützlich in einem Notfall, nicht genau etwas, das Sie als Supportverfahren dokumentieren möchten.

Das Problem

Die Ursache des Problems war die alte PDF-Anzeige-Pipeline innerhalb von AccountView. AccountView enthielt immer noch seinen ursprünglichen versteckten PDF-Anzeiger, der sich auf veraltete Komponenten wie PDFVIEW.OCX und HiQPdf.rda. Diese Komponenten wurden in einer Visual FoxPro-Host-Umgebung eingesetzt, in der Fensterbesitz, COM-Callbacks, Timer, Temp-Dateien, Docking-Panels und ActiveX-Lebenszyklusverhalten von Bedeutung sind.

Die Ersetzung des sichtbaren Betrachters allein war nicht genug. Der alte Betrachter wurde immer noch hinter den Kulissen erstellt, erhielt immer noch Wege, vergrößerte sich immer noch, nahm immer noch am Formularlebenszyklus teil und war immer noch in der Lage AccountView zu destabilisieren. Das war die wichtige Entdeckung: Der neue Betrachter war kein Ersatz für den alten. Es war ein zusätzliches Plugin, das auf das Formular platziert wurde. Der ursprüngliche AccountView PDF-Viewer war versteckt, aber immer noch am Leben.

Das erklärte das seltsame Verhalten: Der neue Betrachter konnte stabil sein, aber der alte versteckte Betrachter konnte die Sitzung noch verderben. Es war wie die Haustür zu reparieren, während die Hintertür noch weit offen war.

Die Fehlerbehebungskämpfe

Die Sitzung begann mit einem Fehler im AccountViews PDF-to-TIFF-Pfad:

PROZEDURE PDF_MANAGER.WRITE_PDF_AS_TIFF Fehlernummer: 1429 Kann den Betriebsbefehl nicht eingestellt werden. Kann nicht geschrieben werden. Fehler 0xE8.

Zuerst war der Verdacht, dass der HiQPdf-Stub unvollständig war. Das Loggen wurde hinzugefügt, damit wir sehen konnten, ob AccountView in Funktionen oder Befehlsbahnen aufruft, die unser Stub noch nicht implementiert hat. Dann wurde die PDF-Beschauerkontrolle ersetzt und getestet. Für eine kurze Zeit sah es stabil aus.

Wir untersuchten dann die FoxPro Temp-Verzeichnisse, den geladenen Prozedurstack, den AccountView Add-in-Code und die neue FoxDocViewer-Integration. Je mehr wir schauten, desto klarer wurde, dass dies kein einziger Fehler war. Es war eine Kettenreaktion:

• Der alte PDF-Schauer war noch aktiv und konnte auf dem neuen Schauer sitzen.
• Der alte Betrachter wurde immer noch durch AccountView-Code vergrößert und gesteuert.
• Der neue Betrachter benötigte strengere Grenzen und den Schutz des Lebenszyklus in einem FoxPro-Formular.
• Fehler bei der Größeänderung, Docking, Dokumentnavigation oder fehlenden Dateien könnten zu AccountView-Statusproblemen führen.
• Vorübergehende FoxPro-Tabellen und Indexe ließen die Symptome wie Datenbankkorruption aussehen, auch wenn der erste Auslöser der Zuschauerlebenszyklus war.

Mehrere Male glaubten wir, dass das System stabil war. Mehrere Male AccountView bewies sofort das Gegenteil. An einem Punkt schien die Anwendung fixed zu sein, nur um sich Momente später aus der Kontrolle zu drehen. An einem anderen Punkt startete sie nicht mehr und zeigte:

Objekt TMS_LIC ist nicht gefunden.

Das war nicht genau die Motivationsbotschaft, die man nach Stunden des Debugging erwartet. Aber es wies uns auf das eigentliche Problem hin: AccountViews Start- und Add-in-Registrierungszustand war instabil geworden. Sobald wir die relevanten internen Registrierungs- / Systemtabellen repariert und neu indexiert hatten, AccountView wieder gestartet. Das war der erste wichtige Wendepunkt.

Die tatsächliche Lösung

Die endgültige Lösung war nicht eine magische Linie, sondern ein verhärter Pass über die gesamte Grenze zwischen AccountView, FoxPro, dem alten Betrachter und dem neuen Betrachter.

Die wichtigsten Änderungen waren:

• Das gefährliche Verhalten des alten PDF-Schausers deaktiviert und noch genug seiner Schnittstelle intakt lassen, so dass AccountView es sicher instanzieren konnte.
• Erstellt wurde ein stabiles PDFVIEW.OCX-Stub die die alte COM-Identität bewahrt, die jedoch die Belastung des instabilen Legacy-Schausers vermeidet.
• Erstellt wurde ein stabiles HiQPdf.rda-Stub Dies führt zu einer konservativen Reaktion und entleert die Stdin, sodass AccountView die Kommunikation des Helferprozesses nicht blockiert.
• Verstärkt die FoxPro-Side-Viewer-Integration Größenänderungen, Docking, Schließen, fehlende Dateien und wiederholte Dokumentänderungen destabilisieren den Host nicht.
• Der neue FoxDocViewer wurde in die richtige Sichtposition gebracht. So bedeckte es nicht mehr AccountView Splitter, Schließenknöpfe oder Ansteckungssteuerungen.
• Entferntes Pfadkartieren nur für die Prüfung So verwendet die Client-Installation die in AccountViews Dokumenttabelle gespeicherten echten Pfade.
• Reinigte und verpackte Endquelle in zwei eigenständige Visual Studio-Lösungen für langfristige Wartung.

Wir haben auch eine verwandte ActiveX-Steuerung, die FileDropArea-Komponente, aus dem gleichen Grund verschärft. Eine Steuerung, die sich gut in ihrem eigenen Fenster verhält, kann immer noch gefährlich in AccountView sein.

Das Ergebnis

Nach den endgültigen Korrekturen wurde das System stark auf Windows 11 Pro mit mehreren Windows, angesteckten und freigesteckten PDF-Viewer-Panels, wiederholtem Scrollen durch Dokumente, fehlenden Dokumenten, echten PDF-Pathen, Größenänderungen und normalen TransportMaster-Workflows getestet.

Das Ergebnis: stabil wie ein Felsen.

Kein Spinning. Kein Temp-Datei-Explosion. Kein versteckter Betrachter kämpft um die oberste Schicht. Kein AccountView-Startfehler. Kein zufällig Korruptions-ähnliches Verhalten nach dem Durchspielen von Aufzeichnungen. Der neue FoxDocViewer zeigte die Dokumente korrekt und blieb durch die Stress-Tests stabil.

Nach ungefähr zehn Stunden Debugging, Test, Breaking, Fixing, Breaking, Reindexing, Rekompiling und gelegentlich die Frage nach allen Lebensmöglichkeiten, die mit vergangenen COM-Steuerungen verbunden sind, endeten wir mit einer stabilen Lösung und sauberen Quellpaketen.

Was wir gelernt haben

In einem Rahmen wie AccountView können versteckte Steuerelemente, alte COM-Identitäten, Formular-Lebenszyklus-Hakker, Docking-Manager, Timer und FoxPro-Template lange weiter teilnehmen, nachdem Sie denken, dass Sie etwas ersetzt haben.

Mit anderen Worten: Wenn eine alte Komponente noch registriert ist, immer noch instantiert ist und immer noch Größeneinstellungen oder Navigationsanrufe erhält, ist sie immer noch Teil des Systems, auch wenn sie nicht zur Sitzung eingeladen wurde.

Wir haben auch gelernt, dass Visual FoxPro-Anwendungen beeindruckend widerstandsfähig und zugleich zutiefst unbarmherzig sein können. Eine falsche Annahme an der COM-Grenze kann wie ein Datenbankproblem aussehen. Ein versteckter Betrachter kann einen neuen Betrachter zerbrochen aussehen lassen. Ein modal Dialog oder ein ungehütetes Callback können eine ansonsten korrekte Integration destabilisieren.

Endzustand

Die Arbeiten wurden nun in geeignetes technisches Material aufgeräumt:

• Ein sauberer Baugewerbe HiQPdf.rda Stub-Lösung.
• Ein sauberer Baugewerbe PDFVIEW.OCX Stub-Lösung.
• Eine verschärfte FoxDocViewer-Integration für AccountView.
• Eine gehärte FileDropArea ActiveX Steuerung, die für zukünftige Einbauvorbereitung vorbereitet ist.
• Eine klare Erklärung, warum das ursprüngliche Verhalten gescheitert ist und warum der neue Ansatz sicherer ist.

Es war eine dieser Sitzungen, in denen jede Antwort zwei neue Fragen erzeugte, und jede this must be it wurde fünf Minuten später von no, wait, it's still spinning. Aber am Ende wurde das System stabilisiert, die Ursachen wurden isoliert, und die letzten Komponenten sind jetzt viel besser geeignet, innerhalb des AccountView-Rahmens zu überleben.

Nicht schlecht für eine Freitag-Debugging-Sitzung, die mit einem PDF-Beschauer begann und sich kurz in eine vollständige Expedition durch die alten COM, Visual FoxPro, AccountView Internals und die emotionalen Grenzen des Kaffees verwandelte.