Dix heures de débogage dans AccountView

Une séance de débogage de dix heures à l'intérieur AccountView: Comment nous avons rendu le lecteur PDF stable à nouveau

Parfois, la maintenance du logiciel est un travail propre et prévisible. Et parfois, c'est dix heures de regarder dans Visual FoxPro, les contrôles ActiveX hérités, les fichiers DBF temporaires, le code compilé scramblé, les téléspectateurs cachés, les composants PDF en panne, et un système de gestion des transports très têtu qui refuse de s'expliquer.

Hier, c'était le deuxième type.

Nous avons passé presque toute une journée de travail à enquêter sur un grave problème de stabilité TransportMaster TMS en cours d'exécution à l'intérieur AccountViewLes symptômes n'étaient pas subtils. Après avoir parcouru quelques dizaines de documents PDF, AccountView commençait à se déchirer. Les fichiers temporaires FoxPro s'accumulaient. L'état interne semblait devenir instable. Dans les pires moments, AccountView ne démarrait plus correctement et signalait des erreurs telles que des objets internes manquants et des définitions de classes corrompues.

La première solution était douloureusement simple: supprimer les fichiers dans le répertoire temporaire de l'utilisateur et essayer à nouveau. Cela a fait que AccountView redémarre, mais bien sûr, ce n'est pas une solution. C'est l'équivalent numérique d'éteindre et de redémarrer l'alimentation du bâtiment parce qu'un interrupteur lumineux est hanté. Utilisant en cas d'urgence, ce n'est pas exactement quelque chose que vous voulez documenter comme une procédure de support.

Le problème

La racine du problème était l'ancien pipeline d'affichage PDF à l'intérieur AccountView. AccountView contenait toujours son affichage PDF caché d'origine, basé sur des composants anciens tels que Les résultats de la recherche et Résultats de l'enquête. Ces composants étaient utilisés dans un environnement hôte Visual FoxPro où la propriété des fenêtres, les rappels COM, les temporisateurs, les fichiers temporaires, les panneaux d'accueil et le comportement du cycle de vie ActiveX sont tous importants.

Le vieil spectateur était encore en train d'être créé dans les coulisses, recevant toujours des chemins, redimensionnant toujours, participant toujours au cycle de vie du formulaire, et toujours capable de déstabiliser AccountView. C'était la découverte importante: le nouveau spectateur n'était pas un substitut pour l'ancien. Le lecteur PDF original AccountView était caché, mais toujours vivant.

Cela expliquait le comportement étrange: le nouveau téléspectateur pouvait être stable, mais l'ancien téléspectateur caché pouvait encore corrompre la session. C'était comme réparer la porte d'entrée alors que la porte arrière était encore largement ouverte.

La bataille de débogage

La session a commencé par une erreur dans le chemin PDF-TIFF AccountViews:

PROCEDURE PDF_MANAGER.WRITE_PDF_AS_TIFF Numéro d'erreur: 1429 Impossible de définir la commande d'opération. Impossible d'écrire. Erreur 0xE8.

Au début, le soupçon était que le fichier HiQPdf était incomplet. La saisie a été ajoutée afin que nous puissions voir si AccountView appelait dans des fonctions ou des chemins de commande que notre fichier n'a pas encore mis en œuvre. Puis le contrôle du spectateur PDF a été remplacé et testé. Pendant un court moment, il a semblé stable. Puis, après avoir parcouru suffisamment de documents, AccountView a commencé à tourner à nouveau.

Nous avons ensuite inspecté les annuaires temporaires FoxPro, la pile de procédures chargée, le code add-in AccountView et la nouvelle intégration FoxDocViewer.

• L'ancien lecteur PDF était toujours actif et pouvait s'asseoir sur le nouveau lecteur.
• L'ancien spectateur était encore redimensionné et contrôlé par le code AccountView.
• Le nouveau spectateur avait besoin de limites plus strictes et de protection du cycle de vie à l'intérieur d'un formulaire FoxPro.
• Les erreurs lors de la redimensionnement, de l'accostement, de la navigation des documents ou des fichiers manquants pourraient se transformer en problèmes d'état AccountView.
• Des tableaux et des indices temporaires FoxPro ont fait ressembler les symptômes à la corruption de la base de données, même lorsque le premier déclencheur était le cycle de vie du spectateur.

Plusieurs fois, nous avons pensé que le système était stable. Plusieurs fois AccountView a immédiatement prouvé le contraire.

L'objet TMS_LIC n'a pas été trouvé.

Ce n'était pas exactement le message de motivation que l'on espérait après des heures de débogage. Mais il nous a poussés vers le vrai problème: AccountView l'état de démarrage et d'ajout d'enregistrement était devenu instable. Une fois que nous avons réparé et réindexé les tables d'enregistrement / système internes pertinentes, AccountView a repris. C'était le premier tournant majeur.

La réparation réelle

La solution finale n'était pas une seule ligne magique, c'était un passage durcissant à travers toute la frontière entre AccountView, FoxPro, l'ancien spectateur et le nouveau spectateur.

Les changements les plus importants ont été:

• Désactiver le comportement dangereux de l'ancien lecteur PDF tout en laissant suffisamment d'interface intacte pour que AccountView puisse l'installer en toute sécurité.
• Création d' un fichier PDFVIEW.OCX stable qui préserve l'ancienne identité COM mais évite de charger le lecteur d'héritage instable.
• Créé un fichier HiQPdf.rda stable qui renvoie une réponse conservatrice et draine le stdin de sorte que AccountView ne bloque pas la communication au processus d'aide.
• Intégration du spectateur côté FoxPro durci Ainsi, les changements de taille, l'accès, la fermeture, les fichiers manquants et les modifications répétées de documents ne déstabilisent pas l'hôte.
• Mettez le nouveau FoxDocViewer dans la position visuelle correcte Il ne couvrait plus les séparateurs, les boutons de fermeture ou les commandes d'accostement.
• Cartographie de trajectoire supprimée uniquement à l'essai Ainsi, l'installation client utilise les chemins réels stockés dans la table de documents AccountView.
• Nettoyage et emballage de la source finale en deux solutions Visual Studio constructibles indépendamment pour une maintenance à long terme.

Nous avons également durci un contrôle ActiveX connexe, le composant FileDropArea, pour la même raison. Un contrôle qui se comporte bien dans sa propre fenêtre peut toujours être dangereux à l'intérieur de AccountView. Les composants ActiveX hébergés doivent être extrêmement conservateurs: pas de dialogues modaux inattendus, pas de rappels COM non surveillés, pas d'hypothèses dangereuses de glisser/déposer, pas d'exceptions de redimensionnement et pas de surprises de cycle de vie.

Le résultat

Après les corrections finales, le système a été fortement testé sur Windows 11 Pro avec plusieurs Windows, des panneaux d'affichage PDF accostés et déconnectés, des défilements répétés à travers les documents, des documents manquants, des pistes PDF réelles, des actions de redimensionnement et des flux de travail TransportMaster normaux.

Le résultat: stable comme une pierre.

Pas de rotation. Pas d'explosion de fichier temporaire. Pas de spectateur caché se battant pour la couche supérieure. Pas d'échec de démarrage AccountView. Pas de comportement de corruption aléatoire après avoir parcouru les enregistrements. Le nouveau FoxDocViewer a montré les documents correctement et est resté stable à travers les tests de stress.

Après environ dix heures de débogage, de test, de rupture, de réparation, de rupture, de réindexation, de recompillage et parfois de remise en question de tous les choix de vie impliquant des commandes COM héritées, nous avons terminé avec une solution stable et des paquets de source propres.

Ce que nous avons appris

La plus grande leçon est que le travail d'intégration traditionnelle ne consiste pas seulement à remplacer le composant visible. Dans un cadre comme AccountView, les commandes cachées, les anciennes identités COM, les crochets du cycle de vie du formulaire, les gestionnaires d'accostement, les temporisateurs et les tables templates FoxPro peuvent tous continuer à participer longtemps après que vous pensiez avoir remplacé quelque chose.

En d'autres termes: si un ancien composant est toujours enregistré, instantané et reçoit encore des appels de redimensionnement ou de navigation, il fait toujours partie du système, même si personne ne l'a invité à la réunion.

Nous avons également appris que les applications Visual FoxPro peuvent être impressionnantes et extrêmement impitoyables en même temps. Une hypothèse erronée à la frontière COM peut ressembler à un problème de base de données. Un spectateur caché peut faire apparaître un nouveau spectateur cassé. Un dialogue modal ou un callback non surveillé peut déstabiliser une intégration autrement correcte.

L'état final

Les travaux ont maintenant été transformés en matériel technique approprié:

• Un bâtiment propre Résultats de l'enquête une solution d'étouffement.
• Un bâtiment propre Les résultats de la recherche une solution d'étouffement.
• Une intégration renforcée de FoxDocViewer pour AccountView.
• Un contrôle durci FileDropArea ActiveX préparé pour une future intégration.
• Une explication claire de pourquoi le comportement initial a échoué et pourquoi la nouvelle approche est plus sûre.

C'était une de ces séances où chaque réponse a créé deux nouvelles questions, et chaque this must be it a été suivi cinq minutes plus tard par no, wait, it's still spinning. Mais à la fin, le système a été stabilisé, les causes profondes ont été isolées, et les composants finaux sont maintenant beaucoup mieux adaptés à survivre à l'intérieur du cadre AccountView.

Pas mal pour une session de débogage du vendredi qui a commencé avec un lecteur PDF et s'est brièvement transformée en une expédition complète à travers l'héritage COM, Visual FoxPro, AccountView internes, et les limites émotionnelles du café.