Actualités
FileDropArea répond à un besoin concret : ajouter aux applications Visual FoxPro anciennes une zone de glisser-déposer moderne et simple pour les fichiers, pièces jointes Outlook et liens, sans réécrire leur socle technique. Le résultat est un contrôle ActiveX exposé via COM, fondé sur .NET Framework 4.8 et conçu pour FoxPro 32 bits.
FileDropArea répond à un besoin d’intégration concret : des applications Visual FoxPro anciennes devaient disposer d’une zone de glisser-déposer moderne et facile à utiliser pour les fichiers, pièces jointes Outlook et liens, sans réécrire leur socle technique. Le résultat est un contrôle ActiveX exposé via COM, développé sur .NET Framework 4.8 et conditionné pour les environnements FoxPro 32 bits.
L’application hôte avait besoin de plus qu’un sélecteur de fichiers. Les utilisateurs voulaient faire glisser des documents depuis l’Explorateur Windows, déposer des pièces jointes Microsoft Outlook, renommer directement les éléments, ouvrir les fichiers liés et déclencher la logique métier avant tout stockage. Rien d’inhabituel dans un environnement .NET ou web moderne ; dans une application de bureau FoxPro, cela exige une conception soigneuse de l’interopérabilité.
Deux contraintes étaient impératives dès le départ. La solution devait se comporter comme un contrôle ActiveX natif dans les formulaires Visual FoxPro. Elle devait aussi rester prévisible dans un environnement COM 32 bits où le déploiement, l’enregistrement et la fiabilité des fonctions de rappel priment sur la nouveauté.
L’implémentation utilise un UserControl WinForms comme support visuel et l’expose par une interface compatible COM. Plutôt que d’employer des interfaces de classe automatiques, le composant définit une interface explicite de commandes et une interface distincte d’événements. Cela stabilise l’interface COM et facilite la documentation et la maintenance du contrat d’intégration avec FoxPro.
Le contrôle expose une API ciblée : ajouter, supprimer ou renommer des éléments, redessiner la zone, activer ou désactiver la copie, définir un dossier de base et déclencher des rappels vers FoxPro lors des actions de l’utilisateur.En interne, le contrôle conserve en mémoire une liste d’éléments de fichiers, chacun représenté par un petit objet de métadonnées contenant un chemin, un identifiant, un type et une description. L’interface utilise une ListView à grandes icônes, tandis que la couche de commandes reste assez simple pour être utilisée aisément depuis FoxPro via COM.
L’interopérabilité COM devient fragile lorsque les membres publics des classes .NET évoluent. Pour l’éviter, le composant utilise une interface par défaut explicite pour les méthodes appelables et une interface de dispatch dédiée aux événements. Nous en avons tiré trois avantages :
Le contrôle visible est volontairement compact : une rangée de boutons en haut et une grande zone de dépôt en dessous. Les boutons couvrent les actions courantes — ajouter, supprimer, ouvrir et afficher les propriétés. La liste permet le glisser-déposer, les rappels lors d’un changement de sélection, l’ouverture par double-clic et le renommage sur place.
Le rendu des icônes s’est révélé important à l’usage. Le contrôle n’affiche pas une icône générique pour tous les fichiers : il extrait les icônes du shell selon l’extension et les met en cache. Les types de fichiers se distinguent ainsi sans interroger constamment le système pour la même icône. Les URL utilisent une icône de navigateur dédiée, pour différencier visuellement les liens des fichiers locaux.
Le glisser-déposer depuis l’Explorateur est simple selon les conventions de Windows. Celui d’Outlook l’est moins. Lorsqu’un utilisateur déplace une pièce jointe, il ne déplace souvent pas un fichier réel présent sur disque, mais des descripteurs de fichiers virtuels et des flux en mémoire, exposés par des formats tels que FileGroupDescriptor et FileContents.
C’était l’un des principaux défis techniques : les données Outlook ressemblent à des fichiers pour l’utilisateur, mais ne parviennent pas au contrôle sous cette forme.Pour les traiter correctement, le contrôle encapsule l’objet de données reçu et normalise les données Outlook. Les pièces jointes sont extraites sous forme de flux, écrites sur disque lorsque nécessaire, puis converties en entrées de liste associées à des fichiers ordinaires. Si l’élément déposé est en réalité une URL provenant d’Outlook, le contrôle suit un parcours distinct et l’enregistre comme lien au lieu de le forcer dans le traitement des pièces jointes.
L’un des choix majeurs est le rappel BeforeFileDrop. Avant de valider un fichier déposé ou sélectionné, le contrôle transmet à FoxPro un objet de paramètres modifiable. L’application FoxPro peut ainsi :
Cet événement transforme un simple composant visuel passif en un point d’intégration conscient des règles de l’application. La logique métier reste dans FoxPro, là où elle doit être, tandis que le contrôle .NET gère les interactions complexes avec Windows.
BeforeFileDrop(FileInfo parameters) - AcceptFile détermine si l’opération se poursuit - FileName peut être modifié avant le stockage - FilePath peut être redirigé vers un autre dossier ou une autre destination - CopyFile détermine si le fichier est copié physiquement ou simplement référencéLe traitement des fichiers s’est révélé plus subtil qu’un simple choix entre copier ou non. Le dépôt depuis l’Explorateur, la sélection manuelle et le dépôt de pièces jointes Outlook reposent sur des situations différentes. Les fichiers ordinaires peuvent déjà exister sur disque et être référencés directement. Les pièces jointes Outlook doivent généralement être matérialisées à partir d’un flux. L’ajout manuel correspond davantage à un import explicite.
L’implémentation sépare ces parcours au lieu de leur imposer un traitement générique unique. Cela rend le code plus compréhensible et réduit les effets de bord, tout en laissant place aux règles propres à l’application. Certaines installations doivent conserver les emplacements source ; d’autres veulent copier tous les fichiers reçus dans un dossier géré, avec des noms uniques.
Il est facile de sous-estimer les rappels d’événements COM jusqu’à ce qu’ils échouent sur le terrain. Un rappel côté FoxPro peut lever une erreur, refuser un état de paramètres ou laisser l’interface hôte dans un état incohérent si le contrôle n’est pas protégé. L’implémentation encadre donc leur exécution et traite leurs échecs comme de véritables cas d’erreur.
Au lieu de laisser une exception interrompre toute l’interaction, le contrôle intercepte l’erreur, consigne les détails de débogage et affiche un message indiquant comment réagir. Dans le parcours BeforeFileDrop, l’échec du rappel entraîne le refus de l’ajout. C’est le bon comportement par défaut : il empêche une opération partielle sur le fichier lorsque la logique métier n’a pas pu s’exécuter correctement.
Dans une intégration de bureau fondée sur COM, la gestion des échecs fait partie de la conception de l’API. L’application hôte et le contrôle doivent réagir ensemble aux défaillances de manière prévisible.Le développement .NET moderne part souvent du principe que la cible est x64. Ce projet ne le pouvait pas : Visual FoxPro est un hôte 32 bits et l’interopérabilité ActiveX doit suivre. Le contrôle est compilé pour x86, enregistré avec la version 32 bits de RegAsm et distribué selon ces contraintes.
Cela semble simple, mais influe sur tout, de la documentation d’enregistrement au diagnostic. Un contrôle techniquement correct, mais enregistré avec les mauvais outils, reste inutilisable en production. Nous avons donc veillé à son inscription correcte comme contrôle ActiveX dans le registre, avec les marqueurs de contrôle insérable et l’enregistrement de son emplacement de code.
Plusieurs petits choix d’implémentation ont beaucoup amélioré l’usage :
FileDropArea illustre un travail souvent essentiel dans le logiciel d’entreprise : prolonger soigneusement les systèmes existants avec des fonctions modernes, plutôt que les remplacer pour le principe. Le défi n’était pas de créer une liste avec glisser-déposer isolée, mais de respecter simultanément FoxPro, COM, Outlook, le shell Windows, les contraintes de déploiement et les attentes des utilisateurs.
Nous apprécions ce type d’arbitrage technique : une intégration de bureau pratique, des interfaces clairement délimitées et une modernisation ciblée qui résout un vrai problème de travail sans déstabiliser le système environnant.
Si vous maintenez une ancienne plateforme de bureau et avez besoin d’interactions modernes sans réécrire son cœur, ce projet montre une approche claire : placer l’intégration complexe au bon endroit, stabiliser le contrat externe et laisser le système hôte conserver la maîtrise des règles métier.
À découvrir
FoxSQL est une passerelle SQL sur TCP/IP pour les données AccountView et Visual FoxPro. Les applications C# utilisent les concepts familiers des bases de données, tandis que le véritable moteur FoxPro continue d’assurer son rôle. Personne n’a à déchiffrer des fichiers DBF à la lueur d’une bougie.
Comment un scanner de tickets est devenu, à partir d’un paquet Swift testable, une plateforme iPhone, iPad et macOS respectueuse de la vie privée : OCR, Core ML, synchronisation CloudKit, exports, outils d’entraînement, audits de production et une compréhension durement acquise des difficultés que les tickets posent au logiciel.
Hamlet est l’un des développements majeurs de notre feuille de route : un éditeur natif de texte enrichi, de mise en page et de publication depuis les données, conçu pour 4D. L’objectif : offrir un éditeur complet intégrable dans un formulaire 4D, utilisant les données réelles de la base pour produire des factures, rapports, lettres, modèles et publications professionnels.
