Dix heures de débogage dans AccountView

Dix heures de débogage dans AccountView : comment nous avons stabilisé la visionneuse PDF

Parfois, la maintenance logicielle est claire et prévisible. Et parfois, elle consiste à passer dix heures face à Visual FoxPro, des contrôles ActiveX anciens, des fichiers DBF temporaires, du code compilé brouillé, des visionneuses cachées, des composants PDF qui plantent et un système de gestion du transport particulièrement obstiné, qui refuse de livrer ses secrets.

Hier, c’était le second cas.

Nous avons consacré presque une journée entière à un grave problème de stabilité de TransportMaster TMS fonctionnant dans AccountView. Les symptômes étaient flagrants. Après quelques dizaines de PDF consultés, AccountView se mettait à tourner en boucle. Les fichiers FoxPro temporaires s’accumulaient et l’état interne semblait se dégrader. Dans les pires moments, AccountView ne démarrait plus correctement et signalait des objets internes manquants et des définitions de classes corrompues. En pratique, l’environnement devenait inutilisable.

Le premier contournement était d’une simplicité désarmante : vider le dossier temporaire de l’utilisateur et réessayer. AccountView redémarrait, mais ce n’était évidemment pas une solution. C’était l’équivalent numérique de couper puis rétablir l’électricité de tout un bâtiment parce qu’un interrupteur semble hanté. Utile en urgence, beaucoup moins comme procédure d’assistance officielle.

Le problème

Le problème provenait de l’ancien mécanisme d’affichage PDF dans AccountView. L’application contenait toujours sa visionneuse d’origine, masquée, reposant sur des composants anciens tels que PDFVIEW.OCX et HiQPdf.rda. Ils fonctionnaient dans un hôte Visual FoxPro, où les relations entre fenêtres, rappels COM, minuteries, fichiers temporaires, panneaux ancrables et cycles de vie ActiveX sont déterminants.

Remplacer uniquement la visionneuse visible ne suffisait pas. L’ancienne était toujours créée en arrière-plan, recevait des chemins, était redimensionnée, participait au cycle de vie des formulaires et pouvait encore déstabiliser AccountView. C’était la découverte essentielle : la nouvelle visionneuse ne remplaçait pas l’ancienne ; c’était un module supplémentaire placé dans le formulaire. La visionneuse PDF d’origine était cachée, mais toujours active.

Cela expliquait les comportements étranges : la nouvelle visionneuse pouvait être stable alors que l’ancienne corrompait encore la session en arrière-plan. C’était réparer la porte d’entrée en laissant celle de derrière grande ouverte.

La bataille du débogage

La session a commencé par une erreur dans le traitement de conversion PDF vers TIFF d’AccountView :

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

Nous avons d’abord soupçonné une implémentation incomplète de notre composant de substitution HiQPdf. Nous avons ajouté des journaux pour voir si AccountView appelait des fonctions ou commandes que ce composant ne gérait pas encore. La visionneuse PDF a ensuite été remplacée et testée. Pendant un moment, tout semblait stable. Puis, après suffisamment de documents parcourus, AccountView s’est remis à tourner en boucle.

Nous avons alors examiné les dossiers temporaires FoxPro, la pile des procédures chargées, le code des extensions AccountView et l’intégration de FoxDocViewer. Plus nous avancions, plus il devenait évident qu’il ne s’agissait pas d’un bug isolé, mais d’une réaction en chaîne :

• l’ancienne visionneuse PDF restait active et pouvait se superposer à la nouvelle ;
• le code AccountView continuait à redimensionner et piloter l’ancienne visionneuse ;
• la nouvelle avait besoin de limites d’affichage et de protections de cycle de vie plus strictes dans le formulaire FoxPro ;
• les erreurs de redimensionnement, d’ancrage, de navigation ou de fichiers manquants pouvaient se propager à l’état interne d’AccountView ;
• les tables et index temporaires FoxPro donnaient l’impression d’une corruption de base, alors que le premier déclencheur était le cycle de vie de la visionneuse.

À plusieurs reprises, nous avons cru le système stable. À plusieurs reprises, AccountView nous a aussitôt prouvé le contraire. L’application paraissait « réparée », puis repartait en boucle quelques instants plus tard. À un autre moment, elle ne démarrait plus et affichait :

Object TMS_LIC is not found.

Ce n’est pas exactement le message encourageant que l’on espère après des heures de débogage. Mais il nous orientait vers le vrai problème : l’état de démarrage et d’enregistrement des extensions d’AccountView était devenu instable. Après réparation et réindexation des tables internes d’enregistrement et du système concernées, AccountView a redémarré. C’était le premier tournant décisif.

La véritable correction

La solution finale ne tenait pas en une ligne magique. Il fallait renforcer toute l’interface entre AccountView, FoxPro, l’ancienne visionneuse et la nouvelle.

Les principales modifications ont été les suivantes :

• Désactiver le comportement dangereux de l’ancienne visionneuse PDF tout en conservant suffisamment de son interface pour qu’AccountView puisse l’instancier sans risque.
• Créer un composant de substitution PDFVIEW.OCX stable qui conserve l’identité COM d’origine sans charger la visionneuse ancienne instable.
• Créer un composant de substitution HiQPdf.rda stable qui renvoie une réponse prudente et lit stdin jusqu’à épuisement pour éviter de bloquer AccountView dans ses échanges avec le processus auxiliaire.
• Renforcer l’intégration côté FoxPro afin que redimensionnement, ancrage, fermeture, fichiers manquants et changements répétés de documents ne déstabilisent pas l’hôte.
• Placer FoxDocViewer correctement dans l’interface pour qu’il ne recouvre plus les séparateurs, boutons de fermeture ou commandes d’ancrage d’AccountView.
• Supprimer la correspondance de chemins réservée aux tests pour que l’installation du client utilise les chemins réels de la table de documents AccountView.
• Nettoyer et préparer le code source final dans deux solutions Visual Studio autonomes et compilables pour la maintenance à long terme.

Nous avons également renforcé FileDropArea, un contrôle ActiveX associé, pour la même raison. Un contrôle qui se comporte bien dans sa propre fenêtre peut rester dangereux dans AccountView. Les composants ActiveX hébergés doivent être très prudents : aucune boîte de dialogue modale inattendue, aucun rappel COM non protégé, aucune hypothèse risquée sur le glisser-déposer, aucune exception de redimensionnement ni surprise de cycle de vie.

Le résultat

Après les dernières corrections, nous avons testé intensivement le système sous Windows 11 Pro : plusieurs fenêtres, panneaux PDF ancrés et détachés, parcours répétés de documents, fichiers manquants, véritables chemins PDF, redimensionnements et opérations habituelles de TransportMaster.

Le résultat : une stabilité à toute épreuve.

Plus de boucles incontrôlées, d’explosion des fichiers temporaires, de visionneuse cachée cherchant à passer au premier plan, d’échec de démarrage ou de comportements aléatoires évoquant une corruption après navigation dans les enregistrements. FoxDocViewer affichait correctement les documents et restait stable pendant les tests de résistance.

Après environ dix heures de débogage, de tests, de pannes, de corrections, de nouvelles pannes, de réindexations, de recompilations et de remises en question occasionnelles de nos choix de vie impliquant COM, nous avons obtenu une solution stable et des sources propres, prêtes à transmettre.

Ce que nous avons appris

La leçon principale est que l’intégration à un ancien système dépasse le remplacement du composant visible. Dans un environnement comme AccountView, des contrôles masqués, identités COM historiques, points d’entrée du cycle des formulaires, gestionnaires d’ancrage, minuteries et tables temporaires FoxPro peuvent continuer à agir longtemps après un remplacement supposé.

Autrement dit, si un composant reste enregistré, instancié et destinataire d’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 aussi constaté que les applications Visual FoxPro peuvent être à la fois étonnamment résistantes et impitoyables. Une mauvaise hypothèse à la frontière COM peut ressembler à un problème de base de données. Une visionneuse cachée peut faire paraître la nouvelle défectueuse. Une boîte modale ou un rappel non protégé peut déstabiliser une intégration par ailleurs correcte.

État final

Le travail a été organisé en livrables techniques propres pour la reprise :

• une solution de substitution HiQPdf.rda propre et compilable ;
• une solution de substitution PDFVIEW.OCX propre et compilable ;
• une intégration FoxDocViewer renforcée pour AccountView ;
• un contrôle ActiveX FileDropArea renforcé, prêt pour de futures intégrations ;
• une explication claire des causes de l’échec initial et de la sûreté accrue de la nouvelle approche.

C’était une de ces sessions où chaque réponse soulève deux nouvelles questions et où chaque « cette fois, c’est bon » est suivi cinq minutes plus tard de « non, attendez, ça tourne encore ». Mais le système a finalement été stabilisé, les causes isolées et les composants sont désormais bien mieux préparés à fonctionner dans AccountView.

Pas mal pour un débogage du vendredi qui commençait par une visionneuse PDF et s’est transformé en expédition à travers COM, Visual FoxPro, les mécanismes internes d’AccountView et les limites du réconfort apporté par le café.