Zehn Stunden Fehlersuche in AccountView

Zehn Stunden Fehlersuche in AccountView: Wie wir den PDF-Betrachter wieder stabil gemacht haben

Manchmal ist Softwarewartung eine überschaubare, planbare Aufgabe. Und manchmal bedeutet sie zehn Stunden mit Visual FoxPro, älteren ActiveX-Steuerelementen, temporären DBF-Dateien, unleserlichem kompiliertem Code, versteckten Betrachtern, abstürzenden PDF-Komponenten und einem ausgesprochen hartnäckigen Transportmanagementsystem, das seine Fehler nicht erklären will.

Gestern war ein Tag der zweiten Sorte.

Fast einen ganzen Arbeitstag lang untersuchten wir ein schwerwiegendes Stabilitätsproblem in TransportMaster TMS innerhalb von AccountView. Die Symptome waren unübersehbar. Nach dem Durchblättern einiger Dutzend PDF-Dokumente geriet AccountView außer Kontrolle. Temporäre FoxPro-Dateien häuften sich, und der interne Zustand schien instabil zu werden. Im schlimmsten Fall startete AccountView nicht mehr korrekt und meldete fehlende interne Objekte oder beschädigte Klassendefinitionen. Praktisch war die Umgebung damit unbenutzbar.

Die erste Notlösung war schmerzhaft einfach: die Dateien im temporären Benutzerverzeichnis löschen und es erneut versuchen. Danach startete AccountView wieder, doch eine Lösung war das natürlich nicht. Es war ungefähr so, als würde man einem ganzen Gebäude den Strom abstellen und wieder einschalten, weil ein Lichtschalter spinnt. Im Notfall nützlich, aber kaum etwas, das man als Supportverfahren dokumentieren möchte.

Das Problem

Die Ursache lag im alten PDF-Anzeigepfad von AccountView. Die Anwendung enthielt weiterhin ihren ursprünglichen, versteckten PDF-Betrachter auf Basis älterer Komponenten wie PDFVIEW.OCX und HiQPdf.rda. Diese Komponenten liefen in einer Visual-FoxPro-Hostumgebung, in der Fensterzuordnung, COM-Rückrufe, Timer, temporäre Dateien, andockbare Bereiche und der Lebenszyklus von ActiveX-Komponenten zusammenwirken.

Nur den sichtbaren Betrachter auszutauschen, reichte nicht aus. Der alte Betrachter wurde im Hintergrund weiterhin erzeugt, erhielt Dateipfade, wurde in der Größe verändert, nahm am Formularlebenszyklus teil und konnte AccountView weiterhin destabilisieren. Das war die entscheidende Erkenntnis: Der neue Betrachter ersetzte den alten nicht, sondern war ein zusätzliches Plugin auf dem Formular. Der ursprüngliche PDF-Betrachter von AccountView war verborgen, aber weiterhin aktiv.

Das erklärte das merkwürdige Verhalten: Der neue Betrachter konnte stabil sein, während der alte, versteckte Betrachter trotzdem die Sitzung beschädigte. Es war, als reparierte man die Haustür, während die Hintertür weiterhin weit offen stand.

Die mühsame Fehlersuche

Die Untersuchung begann mit einem Fehler im PDF-zu-TIFF-Verarbeitungspfad von AccountView:

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

Zunächst vermuteten wir, dass der HiQPdf-Stub unvollständig war. Wir ergänzten Protokollierung, um zu sehen, ob AccountView Funktionen oder Befehle aufrief, die unser Stub noch nicht implementierte. Anschließend wurde das PDF-Steuerelement ersetzt und getestet. Kurzzeitig wirkte alles stabil. Nach dem Durchblättern einer ausreichenden Zahl von Dokumenten geriet AccountView jedoch erneut außer Kontrolle.

Daraufhin untersuchten wir die temporären FoxPro-Verzeichnisse, die geladenen Prozeduren, den AccountView-Add-in-Code und die neue FoxDocViewer-Anbindung. Je genauer wir hinsahen, desto deutlicher wurde: Es war kein einzelner Fehler, sondern eine Kettenreaktion.

• Der alte PDF-Betrachter war weiterhin aktiv und konnte den neuen Betrachter überlagern.
• Der alte Betrachter wurde weiterhin durch AccountView-Code gesteuert und in seiner Größe verändert.
• Der neue Betrachter benötigte strengere Begrenzungen und eine bessere Absicherung seines Lebenszyklus innerhalb eines FoxPro-Formulars.
• Fehler beim Ändern der Größe, Andocken, Wechseln von Dokumenten oder beim Umgang mit fehlenden Dateien konnten weitere Zustandsprobleme in AccountView auslösen.
• Temporäre FoxPro-Tabellen und -Indizes ließen die Symptome wie Datenbankschäden aussehen, obwohl der ursprüngliche Auslöser im Lebenszyklus des Betrachters lag.

Mehrmals glaubten wir, das System sei stabil. Mehrmals bewies AccountView sofort das Gegenteil. Einmal schien die Anwendung „repariert“, nur um kurz darauf wieder außer Kontrolle zu geraten. Ein anderes Mal startete sie nicht mehr und meldete:

Object TMS_LIC is not found.

Nach stundenlanger Fehlersuche war das nicht gerade die erhoffte motivierende Meldung. Sie führte uns aber zum eigentlichen Problem: Der Startzustand und die Add-in-Registrierung von AccountView waren instabil geworden. Nachdem wir die betroffenen internen Registrierungs- und Systemtabellen repariert und neu indiziert hatten, startete AccountView wieder. Das war der erste große Wendepunkt.

Die eigentliche Lösung

Die endgültige Lösung bestand nicht aus einer einzigen genialen Codezeile. Wir mussten den gesamten Übergang zwischen AccountView, FoxPro, dem alten und dem neuen Betrachter robuster machen.

Die wichtigsten Änderungen waren:

• Das gefährliche Verhalten des alten PDF-Betrachters wurde deaktiviert. Genug von seiner Schnittstelle blieb jedoch erhalten, damit AccountView ihn sicher instanziieren konnte.
• Ein stabiler PDFVIEW.OCX-Stub wurde erstellt. Er bewahrt die alte COM-Identität, lädt aber den instabilen ursprünglichen Betrachter nicht mehr.
• Ein stabiler HiQPdf.rda-Stub wurde erstellt. Er liefert eine zurückhaltende Antwort und liest stdin vollständig aus, damit AccountView bei der Kommunikation mit dem Hilfsprozess nicht blockiert.
• Die FoxPro-seitige Viewer-Anbindung wurde abgesichert. Größenänderungen, Andocken, Schließen, fehlende Dateien und wiederholte Dokumentwechsel destabilisieren die Hostanwendung dadurch nicht mehr.
• Der neue FoxDocViewer wurde korrekt positioniert. Er verdeckt keine Trennleisten, Schließen-Schaltflächen oder Andockelemente von AccountView mehr.
• Die ausschließlich für Tests vorgesehene Pfadzuordnung wurde entfernt. Die Kundeninstallation verwendet nun die tatsächlichen Pfade aus der Dokumenttabelle von AccountView.
• Der endgültige Quellcode wurde bereinigt und verpackt. Für die langfristige Wartung stehen zwei eigenständig kompilierbare Visual-Studio-Solutions bereit.

Aus demselben Grund haben wir auch das verwandte ActiveX-Steuerelement FileDropArea robuster gemacht. Eine Komponente, die in ihrem eigenen Fenster gut funktioniert, kann innerhalb von AccountView dennoch gefährlich sein. Eingebettete ActiveX-Komponenten müssen äußerst vorsichtig arbeiten: keine unerwarteten modalen Dialoge, keine ungeschützten COM-Rückrufe, keine unsicheren Drag-and-Drop-Annahmen, keine Ausnahmen bei Größenänderungen und keine Überraschungen im Lebenszyklus.

Das Ergebnis

Nach den abschließenden Korrekturen wurde das System unter Windows 11 Pro intensiv getestet: mit mehreren Fenstern, angedockten und frei schwebenden PDF-Bereichen, wiederholtem Durchblättern, fehlenden Dokumenten, realen PDF-Pfaden, Größenänderungen und normalen TransportMaster-Arbeitsabläufen.

Das Ergebnis: absolut stabil.

Keine Endlosschleifen. Keine explosionsartige Zunahme temporärer Dateien. Kein versteckter Betrachter, der sich in den Vordergrund drängt. Keine Startfehler in AccountView. Keine scheinbar zufälligen Datenbeschädigungen nach dem Durchblättern von Datensätzen. Der neue FoxDocViewer zeigte die Dokumente korrekt an und blieb auch unter Belastung stabil.

Nach ungefähr zehn Stunden Fehlersuche, Tests, Defekten, Reparaturen, weiteren Defekten, Neuindizierung, erneutem Kompilieren und gelegentlichem Zweifel an allen Lebensentscheidungen, die mit alten COM-Steuerelementen zu tun hatten, standen am Ende eine stabile Lösung und saubere Quellcodepakete.

Was wir gelernt haben

Die wichtigste Erkenntnis: Bei der Anbindung an Altsysteme genügt es nicht, die sichtbare Komponente zu ersetzen. In einem Framework wie AccountView können versteckte Steuerelemente, alte COM-Identitäten, Formularereignisse, Docking-Manager, Timer und temporäre FoxPro-Tabellen noch lange weiterwirken, nachdem man glaubt, etwas ausgetauscht zu haben.

Anders gesagt: Solange eine alte Komponente registriert ist, instanziiert wird und Aufrufe für Größenänderungen oder Navigation erhält, gehört sie weiterhin zum System. Auch wenn niemand sie mehr dabeihaben wollte.

Außerdem zeigte sich, dass Visual-FoxPro-Anwendungen gleichzeitig beeindruckend widerstandsfähig und ausgesprochen unnachgiebig sein können. Eine falsche Annahme an der COM-Grenze kann wie ein Datenbankproblem aussehen. Ein versteckter Betrachter kann einen neuen Betrachter defekt erscheinen lassen. Ein modaler Dialog oder ein ungeschützter Rückruf kann eine ansonsten korrekte Integration destabilisieren.

Der Stand nach Abschluss

Die Ergebnisse wurden inzwischen für eine geordnete technische Übergabe aufbereitet:

• Eine bereinigte, kompilierbare Solution für den HiQPdf.rda-Stub.
• Eine bereinigte, kompilierbare Solution für den PDFVIEW.OCX-Stub.
• Eine abgesicherte FoxDocViewer-Anbindung für AccountView.
• Ein robusteres FileDropArea-ActiveX-Steuerelement für künftige Einbettungen.
• Eine klare Erklärung, warum das ursprüngliche Verhalten fehlschlug und weshalb der neue Ansatz sicherer ist.

Es war eine jener Sitzungen, in denen jede Antwort zwei neue Fragen aufwarf und auf jedes „Das muss es sein“ fünf Minuten später ein „Nein, Moment, es hängt immer noch“ folgte. Am Ende wurde das System jedoch stabilisiert, die Ursachen wurden eingegrenzt, und die endgültigen Komponenten sind nun wesentlich besser für den Betrieb innerhalb von AccountView geeignet.

Kein schlechtes Ergebnis für eine Fehlersuche am Freitag, die mit einem PDF-Betrachter begann und vorübergehend zu einer Expedition durch altes COM, Visual FoxPro, die Interna von AccountView und die Grenzen dessen wurde, was Kaffee noch retten kann.