Neuigkeiten
FileDropArea wurde entwickelt, um ein konkretes Integrationsproblem zu lösen: Bestehende Visual-FoxPro-Anwendungen benötigten einen modernen, benutzerfreundlichen Bereich zum Ablegen von Dateien, Outlook-Anhängen und Links, ohne dass die aufnehmende Anwendung neu geschrieben werden musste. Das Ergebnis ist ein über COM zugängliches ActiveX-Steuerelement auf Basis von .NET Framework 4.8, das für 32-Bit-FoxPro-Umgebungen bereitgestellt wird.
FileDropArea wurde entwickelt, um ein konkretes Integrationsproblem zu lösen: Bestehende Visual-FoxPro-Anwendungen benötigten einen modernen, benutzerfreundlichen Bereich zum Ablegen von Dateien, Outlook-Anhängen und Links, ohne dass die aufnehmende Anwendung neu geschrieben werden musste. Das Ergebnis ist ein über COM zugängliches ActiveX-Steuerelement auf Basis von .NET Framework 4.8, das für 32-Bit-FoxPro-Umgebungen bereitgestellt wird.
Die aufnehmende Anwendung brauchte mehr als einen einfachen Dateiauswahldialog. Benutzer wollten Dokumente direkt aus dem Windows-Explorer hereinziehen, Anhänge aus Microsoft Outlook ablegen, Einträge direkt umbenennen, verknüpfte Dateien öffnen und anwendungsspezifische Geschäftslogik ausführen, bevor etwas gespeichert wird. In einer modernen .NET- oder Webumgebung ist das nichts Ungewöhnliches. In einer FoxPro-Desktopumgebung verlangt es jedoch eine sorgfältig entworfene Interoperabilität.
Von Beginn an gab es zwei feste Vorgaben. Erstens musste sich die Lösung in Visual-FoxPro-Formularen wie ein natives ActiveX-Steuerelement verhalten. Zweitens musste sie in einer 32-Bit-COM-Umgebung berechenbar bleiben, in der Bereitstellung, Registrierung und zuverlässige Rückrufe wichtiger sind als technische Neuheit.
Als visuelle Grundlage dient ein WinForms-UserControl, das über eine COM-kompatible Schnittstelle bereitgestellt wird. Statt automatisch erzeugte Klassenschnittstellen zu nutzen, definiert die Komponente eine ausdrückliche Befehlsschnittstelle und eine getrennte Ereignisschnittstelle. So bleibt die COM-Schnittstelle stabil, und die Anforderungen an die FoxPro-Anbindung lassen sich wesentlich leichter dokumentieren und pflegen.
Das Steuerelement bietet eine gezielte API zum Hinzufügen, Entfernen und Umbenennen von Einträgen, zum Neuzeichnen der Oberfläche, zum Umschalten des Kopierverhaltens, zum Festlegen eines Basisverzeichnisses und zum Auslösen von Ereignisrückrufen an FoxPro bei Benutzeraktionen.Intern verwaltet das Steuerelement eine Liste von Dateieinträgen im Arbeitsspeicher. Jeder Eintrag besteht aus einem kompakten Metadatenobjekt mit Pfad, ID, Typ und Beschreibung. Die Oberfläche verwendet eine ListView mit großen Symbolen. Die Befehlsschicht bleibt zugleich einfach genug, damit FoxPro bequem über COM darauf zugreifen kann.
COM-Interoperabilität wird anfällig, wenn sich öffentliche Mitglieder von .NET-Klassen im Laufe der Zeit verändern. Deshalb verwendet die Komponente eine explizite Standardschnittstelle für aufrufbare Methoden und eine eigene Dispatch-Schnittstelle für Ereignisse. Das bietet drei Vorteile:
Das sichtbare Steuerelement ist bewusst kompakt: oben eine Schaltflächenleiste, darunter ein großer Ablagebereich. Die Leiste bietet häufige Aktionen wie Hinzufügen, Löschen, Öffnen und Eigenschaften. Die darunterliegende Listenansicht unterstützt Drag-and-Drop, Rückrufe bei Auswahländerungen, das Öffnen per Doppelklick und das direkte Umbenennen von Einträgen.
In der Praxis erwies sich die Darstellung der Symbole als wichtiges Detail. Das Steuerelement zeigt nicht für jede Datei dasselbe allgemeine Symbol. Es ermittelt anhand der Dateiendung das passende Shell-Symbol und speichert es zwischen. Dadurch sind Dateitypen visuell unterscheidbar, ohne dass die Shell dasselbe Symbol wiederholt liefern muss. URL-Einträge erhalten ein eigenes browserähnliches Symbol, damit sich verlinkte Inhalte deutlich von Dateien unterscheiden.
Drag-and-Drop aus dem Explorer ist nach den Maßstäben der Windows-Desktopentwicklung unkompliziert. Bei Outlook ist das anders. Wenn Benutzer Anhänge aus Outlook ziehen, stammen diese oft nicht als echte Dateien von der Festplatte. Übergeben werden virtuelle Dateibeschreibungen und Datenströme im Arbeitsspeicher, die Outlook über Formate wie FileGroupDescriptor und FileContents bereitstellt.
Das war eine der zentralen technischen Herausforderungen: Für Benutzer sehen Outlook-Daten wie Dateien aus, beim Steuerelement kommen sie jedoch in anderer Form an.Damit der Rest der Komponente diese Daten einheitlich verarbeiten kann, kapselt das Steuerelement das eingehende Datenobjekt und normalisiert die Outlook-Nutzdaten. Anhänge werden als Streams extrahiert, bei Bedarf auf die Festplatte geschrieben und anschließend in gewöhnliche Listeneinträge mit zugrunde liegenden Dateien umgewandelt. Handelt es sich beim abgelegten Inhalt stattdessen um eine URL aus Outlook, erkennt das Steuerelement diesen Fall gesondert und speichert einen URL-Eintrag, statt ihn durch die Anhangsverarbeitung zu schleusen.
Eine der wichtigsten Entwurfsentscheidungen war der Rückruf BeforeFileDrop. Bevor eine abgelegte oder ausgewählte Datei endgültig übernommen wird, übergibt das Steuerelement ein veränderbares Parameterobjekt an FoxPro. Damit kann die FoxPro-Anwendung:
Dieses Ereignis macht aus einem passiven Oberflächenelement einen Integrationspunkt, der die umgebende Anwendung berücksichtigt. Die Geschäftsregeln bleiben in FoxPro, wo sie hingehören. Das .NET-Steuerelement übernimmt die anspruchsvollen Interaktionen mit Windows.
BeforeFileDrop(FileInfo parameters) - AcceptFile legt fest, ob der Vorgang fortgesetzt wird - FileName kann vor dem Speichern geändert werden - FilePath kann auf einen anderen Ordner oder ein anderes Ziel gesetzt werden - CopyFile legt fest, ob die Datei tatsächlich kopiert oder nur verknüpft wirdDie Dateiverarbeitung erwies sich als vielschichtiger als die Entscheidung „kopieren oder nicht kopieren“. Das Ablegen aus dem Explorer, die manuelle Dateiauswahl und das Ablegen von Outlook-Anhängen haben jeweils andere Voraussetzungen. Normale Dateien können bereits auf der Festplatte liegen und direkt referenziert werden. Outlook-Anhänge müssen meist erst aus einem Datenstrom als echte Datei erzeugt werden. Manuelles Hinzufügen entspricht eher einem ausdrücklichen Importvorgang.
Die Umsetzung trennt diese Abläufe, statt sie in einen einzigen allgemeinen Verarbeitungspfad zu zwingen. Das macht den Code leichter verständlich und verringert Nebenwirkungen. Außerdem lässt es Raum für anwendungsspezifische Regeln: Manche Installationen sollen Dateien an ihrem ursprünglichen Ort belassen; andere sollen jede eingehende Datei mit einem eindeutigen Namen in einen verwalteten Speicherordner kopieren.
COM-Ereignisrückrufe werden leicht unterschätzt, bis sie im Betrieb fehlschlagen. Ein Rückruf auf der FoxPro-Seite kann einen Fehler auslösen, einen Parameterzustand ablehnen oder die aufnehmende Oberfläche in einem inkonsistenten Zustand hinterlassen, wenn das Steuerelement sich nicht dagegen absichert. Deshalb wird die Rückrufausführung gekapselt, und fehlgeschlagene Ereignisse werden ausdrücklich als Fehlerfälle behandelt.
Statt eine Ausnahme aus einem Rückruf die gesamte Interaktion unterbrechen zu lassen, fängt das Steuerelement den Fehler ab, protokolliert Diagnosedetails und zeigt eine Fehlermeldung mit einer Handlungsmöglichkeit. Bei BeforeFileDrop wird ein fehlgeschlagener Rückruf wie ein abgelehnter Hinzufügevorgang behandelt. Diese Voreinstellung verhindert unvollständige Dateioperationen, wenn die Geschäftslogik nicht erfolgreich ausgeführt werden konnte.
Bei einer COM-basierten Desktopintegration gehört die Fehlerbehandlung zum API-Entwurf. Hostanwendung und Steuerelement müssen bei einem Fehler aufeinander abgestimmt und vorhersehbar reagieren.Moderne .NET-Entwicklung setzt oft standardmäßig x64 voraus. Hier war das nicht möglich. Visual FoxPro ist eine 32-Bit-Hostanwendung, und die ActiveX-Interoperabilität muss darauf abgestimmt sein. Das Steuerelement wird für x86 kompiliert, mit der 32-Bit-Version von RegAsm registriert und entsprechend für die Bereitstellung verpackt.
Das klingt einfach, beeinflusst aber alles von der Registrierungsdokumentation bis zur Fehlersuche. Ein technisch korrektes Steuerelement, das mit der falschen Werkzeugkette registriert wurde, funktioniert im Betrieb trotzdem nicht. Zur Umsetzung gehörte deshalb auch die korrekte Registrierung als ActiveX-Steuerelement — einschließlich der Kennzeichnung als einfügbares Steuerelement und der Codebase-Registrierung.
Mehrere kleinere Umsetzungsdetails verbesserten die Benutzerfreundlichkeit erheblich:
FileDropArea zeigt, worauf es in Unternehmenssoftware häufig besonders ankommt: Altsysteme nicht allein um der Erneuerung willen ersetzen, sondern gezielt um moderne Funktionen erweitern. Die technische Aufgabe bestand nicht nur darin, eine Drag-and-Drop-Liste zu entwickeln. Sie musste gleichzeitig FoxPro, COM, Outlook, das Verhalten der Windows-Shell, Bereitstellungsvorgaben und die Erwartungen der Benutzer berücksichtigen.
Solche technischen Abwägungen interessieren uns: praxisgerechte Desktopintegration, klar abgegrenzte Schnittstellen und gezielte Modernisierung, die ein konkretes Problem im Arbeitsablauf löst, ohne das umgebende System zu destabilisieren.
Wenn Sie eine ältere Desktopplattform betreuen und moderne Bedienfunktionen benötigen, ohne den Anwendungskern neu zu schreiben, zeigt dieses Projekt einen klaren Ansatz: Die anspruchsvolle Plattformintegration gehört in die passende Komponente, die externe Schnittstelle bleibt stabil, und die Geschäftsregeln verbleiben unter der Kontrolle der Hostanwendung.
Mehr
FoxSQL ist eine TCP/IP-SQL-Verbindung für Daten aus AccountView und Visual FoxPro. C#-Anwendungen arbeiten mit vertrauten Datenbankkonzepten, während die eigentliche FoxPro-Engine weiterhin ihre bewährte Aufgabe übernimmt. Niemand muss DBF-Dateien bei Kerzenschein entschlüsseln.
Wie aus einem testbaren Swift-Paket ein datenschutzorientierter Belegscanner für iPhone, iPad und macOS wurde — mit OCR, Core ML, CloudKit-Synchronisierung, Exporten, Trainingswerkzeugen, Produktionsprüfungen und der mühsam gewonnenen Erkenntnis, was Kassenbons Software tatsächlich abverlangen.
Hamlet gehört zu den wichtigsten Entwicklungen auf unserer aktuellen Produktroadmap: ein nativer Editor für formatierten Text, Seitenlayout und datenbankgestützte Dokumenterstellung, speziell für 4D. Das Ziel ist anspruchsvoll, aber klar: 4D-Entwickler sollen einen leistungsfähigen Dokumenteditor erhalten, der direkt in einem 4D-Formular arbeitet, echte Datenbankdaten nutzt und professionelle Rechnungen, Berichte, Briefe, Vorlagen und Publikationen erzeugt.
