Actualités
Créer une visionneuse de documents très rapide pour les anciennes applications FoxPro, sans exiger de moderniser d’abord l’application hôte.
Créer une visionneuse de documents très rapide pour les anciennes applications FoxPro, sans exiger de moderniser d’abord l’application hôte.
Ce projet répond à un problème fréquent des logiciels anciens : afficher des documents avec des fonctions modernes dans une application qui n’a pas été conçue pour cela. Ici, l’hôte est Visual FoxPro : la solution devait se comporter comme un contrôle ActiveX classique, exposer une interface COM prudente et stable, rester strictement en 32 bits et éviter toute instabilité susceptible de faire tomber le processus hôte.
Le résultat est FoxDocViewer, une visionneuse native en C++ intégrable directement à un formulaire FoxPro. Elle prend en charge les PDF avec PDFium et les images avec Windows Imaging Component. L’ensemble est exposé par une interface que FoxPro appelle de manière fiable avec des types familiers tels que BSTR, LONG, DOUBLE et VARIANT.
L’architecture est volontairement divisée en couches ciblées : l’enveloppe COM reste réduite et la logique de rendu reste extensible.
Le contrôle ActiveX est développé avec ATL et expose une interface duale pour la liaison tardive et l’accès par vtable. FoxPro peut ainsi piloter la visionneuse par des appels simples : charger une liste de documents, changer de page, ajuster le zoom ou consulter le nombre de pages et le chemin du document actif.
L’un des points subtils est l’acceptation des chemins. FoxPro peut produire des tableaux de formes peu intuitives, à une ou deux dimensions. Le contrôle normalise donc les valeurs SAFEARRAY reçues, déréférence les variantes transmises par référence, convertit les valeurs en chaînes et ignore sans risque les entrées inutilisables au lieu de provoquer un échec brutal.
Derrière la couche ActiveX se trouve un contrôleur de visionneuse dédié. Cette classe ne connaît ni le dessin Win32 ni COM, ce qui garde sa logique claire. Elle gère le document et la page actifs, le mode et le pourcentage de zoom, ainsi que le cycle de vie du cache. Le contrôle lui transmet les commandes puis récupère les données d’affichage préparées.
Cette séparation transforme un composant historiquement complexe en une machine à états prévisible. Le changement de document réinitialise la page active, les modes d’ajustement recalculent le zoom selon la zone d’affichage et l’état d’erreur est conservé à un seul endroit au lieu de se disperser entre les couches.
La visionneuse utilise des adaptateurs distincts selon le type de fichier. Windows Imaging Component décode les JPG et PNG, les convertit dans un format BGRA normalisé sur 32 bits et les redimensionne avec l’interpolation de haute qualité de WIC. Les PDF sont traités par PDFium, chargé dynamiquement à l’exécution plutôt que lié statiquement au contrôle.
Ce chargement dynamique est important pour le déploiement. Si pdfium.dll manque, les images restent utilisables et une erreur spécifique au moteur PDF est signalée à l’ouverture d’un PDF. L’hôte continue de fonctionner : les erreurs d’installation deviennent des situations récupérables à l’exécution plutôt que des échecs d’enregistrement ou de démarrage.
La performance de rendu était une exigence centrale. L’implémentation utilise un cache de pages à capacité limitée, qui évince les éléments les moins récemment utilisés et identifie chaque entrée par document, page et plage de zoom. Les valeurs de zoom sont regroupées en plages pour éviter de renouveler le cache à chaque variation minime. Ce détail améliore fortement la vitesse perçue.
Le contrôle déclenche aussi une minuterie légère qui prépare les pages voisines lorsque l’interface est inactive. La page suivante ou précédente est donc souvent déjà en mémoire au moment de la navigation. Le changement paraît immédiat, tandis que décodage et rastérisation s’effectuent en arrière-plan dans le code natif.
La dernière couche est le moteur de rendu. Il utilise un tampon hors écran et des copies GDI pour dessiner dans la fenêtre du contrôle sans scintillement. Les barres de défilement suivent la taille logique du canevas, les pages sont centrées lorsqu’elles sont plus petites que la zone visible et le tampon ne grandit que lorsque nécessaire pour limiter le coût des redimensionnements.
Ces détails peuvent sembler de bas niveau, mais ils déterminent la confiance dans un logiciel de bureau. Une visionneuse qui produit des déchirures d’image, clignote, se redessine mal ou bloque au redimensionnement paraît immédiatement fragile. L’implémentation l’évite en organisant le dessin comme une chaîne contrôlée plutôt qu’une suite d’appels Win32 improvisés.
L’hôte attend un comportement COM classique, et non un navigateur intégré moderne ou un environnement d’exécution managé. Cela excluait de nombreuses solutions faciles et imposait de respecter ActiveX, l’hébergement 32 bits et le cycle de vie piloté par messages d’un contrôle Windows traditionnel.
Le comportement des tableaux FoxPro peut surprendre au passage de la frontière COM. L’implémentation devait accepter plusieurs formes de VARIANT et de SAFEARRAY, et l’exemple d’intégration montre que ce besoin était concret. Il fallait tenir compte des tableaux réellement produits par FoxPro, au-delà de ce que prévoit la spécification COM.
Les PDF et images haute résolution peuvent rapidement consommer beaucoup de mémoire après rastérisation. Le cache a donc une capacité limitée et évince des entrées, tandis que le regroupement des zooms évite une multitude d’images presque identiques. L’objectif est une réactivité stable dans les usages réels de bureau, plutôt qu’un cache maximal à tout prix.
Un plantage de la visionneuse ferait aussi planter FoxPro. Le contrôle signale donc les erreurs par son état et ses événements, conserve l’ancien contenu à l’écran si un nouveau document ne se charge pas et libère les ressources système de façon déterministe. La stabilité faisait partie de la définition du produit.
FoxDocViewer apporte une visionneuse moderne à une ancienne application métier sans réécrire sa plateforme. Les utilisateurs ouvrent PDF et images dans leur environnement de travail habituel, parcourent les pages rapidement, zooment avec fluidité et passent d’un document à l’autre avec très peu de latence.
Sur le plan technique, le projet illustre une modernisation pragmatique : garder une interface stable et sobre, isoler la logique de chaque format, optimiser les opérations de rendu qui comptent et intégrer dès la conception l’interopérabilité et la gestion des défaillances.
À découvrir
Rose Development a un nouveau site. Plutôt qu’une annonce générale, nous expliquons les choix techniques qui le structurent, car le site illustre concrètement notre manière d’aborder chaque projet.
Tous les quelques années, le secteur du logiciel découvre un outil censé réduire le besoin de programmeurs. Dans les années 1980, c’étaient les langages de quatrième génération et les outils CASE ; dans les années 1990, la programmation visuelle ; dans les années 2000, le développement délocalisé ; dans les années 2010, le low-code et le no-code. Dans les années 2020, c’est le code généré par l’IA.
DataBridge est une plateforme de synchronisation réutilisable qui transfère les données métier d’un environnement de gestion local vers des services HTTP, Microsoft SQL Server ou MySQL. Au-delà d’un export ponctuel, elle établit un lien durable entre des environnements très différents et reste souple même lorsque la structure exacte des données n’est pas connue à l’avance.
