Actualités
FileDropArea apporte aux applications Visual FoxPro existantes un glisser-déposer moderne pour les fichiers, les pièces jointes Outlook et les liens, sans réécrire l’application hôte. Il s’agit d’un contrôle ActiveX visible par COM, basé sur .NET Framework 4.8 pour les environnements FoxPro 32 bits.
FileDropArea a été construit pour résoudre un problème d'intégration pratique: les applications Visual FoxPro antérieures avaient besoin d'une surface de glisser-déposer moderne et conviviale pour les fichiers, les pièces jointes Outlook et les liens, sans réécrire la pile d'applications hôtes. Le résultat était un com-visible ActiveX contrôle construit sur .NET Framework 4.8 et emballé pour les environnements FoxPro à 32 bits.
L'application hôte avait besoin de plus qu'un simple sélecteur de fichiers. Les utilisateurs voulaient glisser des documents directement depuis Windows Explorer, supprimer les pièces jointes de Microsoft Outlook, renommer les éléments en ligne, ouvrir des fichiers liés et déclencher la logique commerciale spécifique à l'application avant que quoi que ce soit ne soit stocké. Dans une pile .NET ou web moderne, rien de cela n'est inhabituel. Dans un environnement de bureau FoxPro, il nécessite une conception interop soigneuse.
Le projet avait deux contraintes dures dès le début. Premièrement, la solution devait se comporter comme un contrôle ActiveX natif à l'intérieur des formulaires Visual FoxPro. Deuxièmement, elle devait rester prévisible dans un monde COM à 32 bits où le déploiement, l'enregistrement et la stabilité des rappels comptent plus que la nouveauté.
La mise en œuvre utilise un WinForms UserControl comme hôte visuel et expose ce contrôle via une interface sécurisée COM. Au lieu de s'appuyer sur des interfaces de classe automatiques, le composant définit une interface de commande explicite et une interface d'événement séparée. Cela importe car il maintient la surface COM stable et rend le contrat d'intégration FoxPro beaucoup plus facile à documenter et à entretenir.
Le contrôle expose une API axée: ajouter des éléments, supprimer des éléments, renommer des éléments, redessiner la surface, changer le comportement de copie, définir un répertoire de base et augmenter les rappels d'événements en FoxPro lorsque des actions de l'utilisateur se produisent.L'interface utilisateur est rendue avec une grande icône ListView, tandis que la couche de commande reste assez simple pour FoxPro de consommer confortablement via COM.
L'interop COM devient fragile lorsque les membres de la classe public .NET dérivent au fil du temps. Pour éviter cela, le composant utilise une interface par défaut explicite pour les méthodes d'appel et une interface dédiée à l'envoi pour les événements. Cela nous a donné trois avantages:
Le contrôle visible est intentionnellement compact: une rangée de boutons sur le dessus et une grande zone de dépôt en dessous. La barre de boutons gère des actions courantes telles que ajouter, supprimer, ouvrir et propriétés.
Un détail qui comptait dans l'utilisation du monde réel était le rendu des icônes. Le contrôle ne montre pas simplement une icône de fichier générique pour tout. Il extrait des icônes de coque par extension de fichier et les cache, de sorte que différents types de fichiers semblent différents sans frapper à plusieurs reprises la coque pour la même icône. Les entrées d'URL sont rendues séparément avec une icône de style navigateur dédiée pour rendre le contenu lié visuellement différent des éléments du système de fichiers.
Le glisser-déposer à partir d'Explorer est simple selon les normes de bureau Windows. Outlook n'est pas. Lorsque les utilisateurs glissent des pièces jointes à partir d'Outlook, ils ne glissent souvent pas de vrais fichiers du disque. Ils glissent des descripteurs de fichiers virtuels et des flux de mémoire exposés à travers des formats de données spécifiques à Outlook tels que FileGroupDescriptor et FileContents.
C'était l'un des défis centraux de l'ingénierie du projet: les données Outlook ressemblent à des fichiers pour l'utilisateur, mais elles n'arrivent pas comme des fichiers au contrôle.Pour gérer cela de manière propre, le contrôle enveloppe l'objet de données entrant et normalise la charge utile Outlook en quelque chose que le reste du composant peut traiter. Les pièces jointes sont extraites sous forme de flux, écrites sur le disque lorsque nécessaire, puis transformées en entrées de liste normales sauvegardées par fichier. Si la charge utile tombée est en fait une URL d'Outlook, le contrôle reconnaît ce chemin séparément et le stocke comme un élément d'URL au lieu de le forcer à travers le pipeline de pièces jointes.
L'une des décisions de conception les plus importantes a été le Callback BeforeFileDrop. Plutôt que de rendre le traitement des fichiers rigide, le contrôle ramène un objet de paramètre changeable à FoxPro avant qu'un fichier abandonné ou sélectionné ne soit engagé. Cela permet à l'application FoxPro de:
Cet événement a transformé le contrôle d'un widget d'interface utilisateur passif en un point d'intégration conscient de l'application. Il a permis aux règles d'affaires de rester dans FoxPro, où elles appartenaient, tandis que le contrôle .NET gérait le travail d'interaction difficile Windows.
BeforeFileDrop(Paramètres d'Info de fichier) - AcceptFile contrôle si l'opération se poursuit - Le nom du fichier peut être modifié avant le stockage - FilePath peut être redirigé vers un dossier ou une cible différent - CopyFile contrôle si le fichier est copié physiquement ou uniquement liéLe traitement des fichiers s'est avéré être plus nuancé que de simplement copier ou de ne pas copier. L'explorateur se déplace, la sélection manuelle de fichiers et l'annexe Outlook se déplace à partir de différentes hypothèses. Les fichiers standard peuvent déjà exister sur le disque et peuvent être référencés directement. Les fichiers joints Outlook doivent généralement être matérialisés à partir d'un flux dans un fichier réel. Les opérations d'ajout manuelles se comportent plus comme une action d'importation explicite.
La mise en œuvre sépare ces flux au lieu de les forcer à travers un seul chemin généralisé. Cela facilite le raisonnement du code et réduit les risques d'effets secondaires. Il laisse également de la place à une politique spécifique à l'application. Par exemple, certains déploiements veulent préserver les emplacements des fichiers source, tandis que d'autres veulent que chaque fichier entrant soit copié dans un dossier de stockage géré avec des noms uniques.
Les rappels d'événements COM sont faciles à sous-estimer jusqu'à ce qu'ils échouent dans le champ. Un rappel de côté FoxPro peut lancer une erreur, rejeter un état de paramètre ou laisser l'interface utilisateur hôte dans un moment incohérent si le contrôle ne se défend pas. C'est pourquoi l'implémentation enveloppe l'exécution des rappels et traite les défaillances d'événements comme des cas d'erreur de première classe.
Au lieu de laisser une exception d'appel de retour déchirer l'interaction, le contrôle capte les défaillances, enregistre les détails de débogage et affiche un message d'erreur actionable. Dans le chemin BeforeFileDrop, l'échec d'appel de retour est traité comme une opération d'ajout rejetée. C'est la bonne opération par défaut car il empêche les opérations de fichier partielles lorsque la logique d'affaires ne pouvait pas s'exécuter avec succès.
Dans l'intégration de bureau basée sur COM, la gestion des défaillances fait partie de la conception de l'API.Le développement moderne .NET suppose souvent x64 par défaut. Ce projet ne pouvait pas. Visual FoxPro est un hôte 32 bits, et ActiveX l'interopérabilité suit cette réalité.
Cela semble simple, mais cela affecte tout, de la documentation d'enregistrement au dépannage. Un contrôle qui est techniquement correct mais enregistré avec la mauvaise chaîne d'outils est toujours cassé dans la production. Une partie du travail de mise en œuvre était de s'assurer que le composant se comporte comme un contrôle ActiveX approprié dans le registre, y compris les marqueurs de contrôle insertables et l'enregistrement de base de code.
Plusieurs petits détails de mise en œuvre ont eu un impact énorme sur la convivialité:
FileDropArea est un bon exemple du travail qui compte le plus souvent dans le logiciel d'entreprise: ne pas remplacer les systèmes anciens pour le bien de celui-ci, mais les étendre soigneusement avec des capacités modernes. Le défi technique n'était pas de construire une liste de glisser-déposer isolée. Il a été de construire une liste qui respectait FoxPro, COM, Outlook, Windows comportement de coquille, contraintes de déploiement, et les attentes des utilisateurs en même temps.
C'est le genre d'échange d'ingénierie que nous apprécions: intégration pratique des ordinateurs de bureau, des limites d'interface fortes et une modernisation ciblée qui résout un vrai problème de flux de travail sans déstabiliser le système qui l'entoure.
Si vous maintenez une plateforme de bureau ancienne et que vous avez besoin d'un comportement d'interface utilisateur moderne sans réécrire le cœur de l'application, ce projet montre clairement le schéma: placez l'intégration difficile de la plateforme là où elle appartient, gardez le contrat externe stable et laissez le système hôte garder la propriété des règles d'affaires.
À découvrir
FoxSQL est une passerelle SQL sur TCP/IP pour les données AccountView et Visual FoxPro. Les applications C# utilisent des concepts de base de données familiers, tandis que le moteur FoxPro continue d’exécuter son travail natif.
Lire la suiteComment un scanner de reçus est devenu une plateforme respectueuse de la vie privée pour iPhone, iPad et macOS, avec OCR, Core ML, synchronisation CloudKit, exports, outils d’entraînement et contrôles de production.
Lire la suiteHamlet est un éditeur natif de texte enrichi, de mise en page et de publication à partir de bases de données, conçu pour 4D. Son objectif : produire des documents professionnels avec de vraies données, directement dans un formulaire 4D.
Lire la suite
