Neuigkeiten
FileDropArea bietet bestehenden Visual-FoxPro-Anwendungen modernes Drag-and-drop für Dateien, Outlook-Anhänge und Links, ohne den Anwendungsbestand neu zu schreiben. Das Ergebnis ist ein COM-sichtbares ActiveX-Steuerelement auf .NET Framework 4.8 für 32-Bit-FoxPro-Umgebungen.
FileDropArea wurde entwickelt, um ein praktisches Integrationsproblem zu lösen: Veraltete Visual FoxPro-Anwendungen benötigten eine moderne, benutzerfreundliche Drag-and-Drop-Oberfläche für Dateien, Outlook-Anhänge und Links, ohne den Host-Anwendungsstack neu zu schreiben. Das Ergebnis war eine COM-sichtbare ActiveX-Steuerung, die auf .NET Framework 4.8 basiert und für 32-Bit FoxPro-Umgebungen verpackt wurde.
Die Host-Anwendung benötigte mehr als nur einen einfachen Dateipiecker. Benutzer wollten Dokumente direkt aus Windows Explorer ziehen, Anhänge aus Microsoft Outlook fallen lassen, Elemente inline umbenennen, verknüpfte Dateien öffnen und die anwendungsspezifische Geschäftslogik auslösen, bevor etwas gespeichert wurde. In einem modernen .NET oder Webstack ist nichts Ungewöhnliches. In einer FoxPro Desktop-Umgebung erfordert es sorgfältiges Interop-Design.
Das Projekt hatte von Anfang an zwei schwere Einschränkungen. Erstens musste sich die Lösung wie eine native ActiveX-Steuerung innerhalb von Visual FoxPro Formen verhalten. Zweitens musste sie in einer 32-Bit-COM-Welt vorhersehbar bleiben, in der Einsatz, Registrierung und Rückrufstabilität wichtiger sind als Neuheit.
Die Implementierung verwendet einen WinForms UserControl als visuellen Host und zeigt diese Steuerung durch eine COM-sichere Schnittstelle. Anstatt sich auf automatische Klassen-Schnittstellen zu verlassen, definiert die Komponente eine explizite Befehlsschnittstelle und eine separate Ereignis-Schnittstelle. Das ist wichtig, weil es die COM-Oberfläche stabil hält und den FoxPro Integrationsvertrag viel einfacher zu dokumentieren und zu pflegen macht.
Die Steuerung zeigt eine fokussierte API auf: fügen Sie Elemente hinzu, entfernen Sie Elemente, benennen Sie Elemente um, zeichnen Sie die Oberfläche neu, wechseln Sie das Kopieverhalten, setzen Sie ein Basisverzeichnis und erhöhen Sie die Callbacks von Ereignissen in FoxPro, wenn Benutzeraktionen auftreten.Intern unterhält die Steuerung eine Speicherliste von Dateielementen, die jeweils durch ein kompaktes Metadatenobjekt mit einem Pfad, ID, Typ und Beschreibung dargestellt werden. Die Benutzeroberfläche wird mit einem großen Symbol ListView erstellt, während die Befehlsschicht einfach genug bleibt, um FoxPro bequem über COM zu konsumieren.
COM-Interop wird zerbrechlich, wenn öffentliche .NET-Klassenmitglieder im Laufe der Zeit abweichen. Um dies zu vermeiden, verwendet die Komponente eine explizite Standardoberfläche für anrufbare Methoden und eine dedizierte Dispatch-Schnittstelle für Ereignisse. Das gab uns drei Vorteile:
Die sichtbare Steuerung ist absichtlich kompakt: eine Schaltfläche auf der Oberseite und ein großer Drop-Bereich unten. Die Schaltfläche behandelt häufige Aktionen wie Hinzufügen, Löschen, Öffnen und Eigenschaften.
Ein Detail, das bei der Verwendung in der realen Welt von Bedeutung war, war die Renderung von Symbolen. Die Steuerung zeigt nicht einfach ein generisches Datei-Symbol für alles. Es extrahiert Shell-Symbolen per Datei-Erweiterung und caches sie, so dass verschiedene Dateitypen unterschiedlich aussehen, ohne immer wieder die Shell für das gleiche Symbol zu treffen. URL-Einträge werden separat mit einem speziellen Browser-Stil-Symbol dargestellt, um verknüpfte Inhalte visuell von Datei-System-Elemente zu unterscheiden.
Drag-and-drop von Explorer ist durch Windows Desktop-Standards einfach. Outlook ist nicht. Wenn Benutzer Anhänge aus Outlook ziehen, ziehen sie oft keine echten Dateien von der Festplatte. Sie ziehen virtuelle Dateibeschreibungen und Speicherströme, die durch Outlook-spezifische Datenformate wie FileGroupDescriptor und FileContents ausgesetzt sind.
Dies war eine der zentralen technischen Herausforderungen des Projekts: Outlook-Daten sehen dem Benutzer wie Dateien aus, kommen aber nicht wie Dateien an die Steuerung.Um das sauber zu behandeln, wickelt die Steuerung das eingehende Datenobjekt und normalisiert die Outlook-Nutzkosten in etwas, das der Rest der Komponente verarbeiten kann. Wenn die abgewiesene Nutzlast tatsächlich eine URL von Outlook ist, erkennt die Steuerung diesen Weg separat und speichert ihn als URL-Element anstatt ihn durch die Anhänge zu zwingen.
Eine der wichtigsten Entwurfsentscheidungen war der Callback von BeforeFileDrop. Anstatt das File-Handling steif zu machen, erhöht die Steuerung ein veränderbares Parameterobjekt auf FoxPro, bevor eine abgewiesene oder ausgewählte Datei eingesetzt wird. Das ermöglicht der FoxPro-Anwendung:
Dieses Ereignis verwandelte die Steuerung von einem passiven Benutzeroberfläche-Widget in einen anwendungsbewussten Integrationspunkt. Es ermöglichte es den Geschäftsregeln, in FoxPro zu bleiben, wo sie hingehörten, während die .NET Steuerung die schwierige Windows Interaktionsarbeit bearbeitete.
BeforeFileDrop(FileInfo-Parameter) - AcceptFile kontrolliert, ob die Operation weitergeht - FileName kann vor dem Speichern geändert werden - FilePath kann an einen anderen Ordner oder Ziel weitergeleitet werden - CopyFile kontrolliert, ob die Datei physisch kopiert oder nur verknüpft istDas Handling von Dateien erwies sich als nuancierter als einfach kopieren oder nicht kopieren. Explorer-Abläufe, manuelle Datei-Auswahl und Outlook-Anhänge fallen jeweils aus verschiedenen Annahmen aus. Standard-Dateien können bereits auf der Festplatte vorhanden sein und können direkt verwiesen werden. Outlook-Anhänge müssen normalerweise aus einem Stream in eine echte Datei materialisiert werden. Manuelle Add-Operationen verhalten sich eher wie eine explizite Importaktion.
Die Implementierung trennt diese Flüsse anstatt sie durch einen einzigen verallgemeinerten Pfad zu zwingen. Das macht den Code einfacher zu begründen und reduziert die Wahrscheinlichkeit von Nebenwirkungen. Es lässt auch Raum für anwendungsspezifische Richtlinien. Zum Beispiel wollen einige Implementierungen die Standorte der Quelldateien bewahren, während andere alle eingehenden Dateien in einen verwalteten Speicherordner mit einzigartigen Namen kopieren möchten.
COM-Event-Callbacks können leicht unterschätzt werden, bis sie im Feld fehlen. Ein FoxPro-Side-Callback kann einen Fehler auswerfen, einen Parameterzustand ablehnen oder die Host-UI in einem inkonsistenten Moment verlassen, wenn die Steuerung sich nicht selbst verteidigt.
Anstatt eine Rückruf-Ausnahme durch die Interaktion zu reißen, erfasst die Steuerung Fehler, logt Debug-Details und zeigt eine handlungsfähige Fehlermeldung an. Im Path BeforeFileDrop wird Rückruffehler als abgelehntes Add-Operation behandelt. Das ist die richtige Standardoperation, da sie teilweise Dateibetrieb verhindert, wenn Geschäftslogik nicht erfolgreich ausgeführt werden konnte.
In der COM-basierten Desktop-Integration ist die Fehlerbearbeitung Teil des API-Designs. Die Host-Anwendung und die Steuerung müssen vorhersehbar zusammen versagen.Die moderne .NET-Entwicklung nimmt häufig x64 standardmäßig an. Dieses Projekt konnte nicht. Visual FoxPro ist ein 32-Bit-Host, und ActiveX Interoperabilität folgt dieser Realität. Die Steuerung wird für x86 kompiliert, durch 32-Bit RegAsm registriert und mit dieser Bereitstellung Geschichte im Hinterkopf verpackt.
Das klingt einfach, aber es betrifft alles von der Registrierungsdokumentation bis zur Fehlerbehebung. Eine Kontrolle, die technisch korrekt ist, aber mit der falschen Werkzeugkette registriert ist, ist in der Produktion immer noch kaputt. Ein Teil der Implementierungsarbeit bestand darin, sicherzustellen, dass sich die Komponente wie eine ordnungsgemäße ActiveX-Steuerung im Registry verhält, einschließlich einfügbarer Kontrollmarker und Codebase-Registrierung.
Mehrere kleinere Implementierungsdetails hatten einen außerordentlichen Einfluss auf die Benutzerfreundlichkeit:
FileDropArea ist ein gutes Beispiel für die Arbeit, die in der Unternehmenssoftware oft am wichtigsten ist: nicht die Ersetzung von Legacy-Systemen, sondern die sorgfältige Erweiterung mit modernen Fähigkeiten. Die technische Herausforderung bestand nicht darin, eine Drag-and-Drop-Liste isoliert zu erstellen. Es ging darum, eine zu erstellen, die FoxPro, COM, Outlook, Windows Shell-Verhalten, Einsatzbeschränkungen und Benutzererwartungen gleichzeitig respektierte.
Das ist die Art von Engineering-Tradeoff, die wir genießen: praktische Desktop-Integration, starke Schnittstellengrenzen und gezielte Modernisierung, die ein echtes Workflow-Problem löst, ohne das System um sie herum zu destabilisieren.
Wenn Sie eine alte Desktop-Plattform aufrechterhalten und ein modernes UI-Verhalten benötigen, ohne den Anwendungskern neu zu schreiben, zeigt dieses Projekt das Muster klar: Setzen Sie die schwierige Plattformintegration dort, wo sie hingehört, halten Sie den externen Vertrag stabil und lassen Sie das Host-System den Besitz der Geschäftsregeln behalten.
Mehr
FoxSQL ist eine TCP/IP-SQL-Brücke für Daten aus AccountView und Visual FoxPro. C#-Anwendungen arbeiten mit vertrauten Datenbankbegriffen, während die FoxPro-Engine weiterhin ihre eigentliche Aufgabe übernimmt.
WeiterlesenWie aus einem Belegscanner ein datenschutzorientiertes System für iPhone, iPad und macOS entstand — mit OCR, Core ML, CloudKit-Synchronisation, Exporten, Trainingswerkzeugen und Produktionsprüfungen.
WeiterlesenHamlet ist ein nativer Editor für Rich Text, Seitenlayout und datenbankgestützte Publikationen, speziell für 4D. Das Ziel: professionelle Dokumente mit echten Daten direkt in einem 4D-Formular erstellen.
Weiterlesen
