Nieuws

FileDropArea: een ActiveX-component voor slepen en neerzetten in FoxPro, gebouwd op .NET

FileDropArea lost een praktisch integratieprobleem op: bestaande Visual FoxPro-applicaties hadden een modern, gebruiksvriendelijk vlak nodig voor het slepen en neerzetten van bestanden, Outlook-bijlagen en links, zonder de omringende applicatie te herschrijven. Het resultaat is een via COM toegankelijke ActiveX-component op .NET Framework 4.8, geschikt gemaakt voor 32-bits FoxPro-omgevingen.

FileDropArea: een ActiveX-component voor slepen en neerzetten in FoxPro, gebouwd op .NET

FileDropArea: een ActiveX-component voor slepen en neerzetten in FoxPro, gebouwd op .NET

Portfolioartikel | ROSE Development | ActiveX, COM-interoperabiliteit, Visual FoxPro, Windows-desktopintegratie

FileDropArea lost een praktisch integratieprobleem op: bestaande Visual FoxPro-applicaties hadden een modern, gebruiksvriendelijk vlak nodig voor het slepen en neerzetten van bestanden, Outlook-bijlagen en links, zonder de omringende applicatie te herschrijven. Het resultaat is een via COM toegankelijke ActiveX-component op .NET Framework 4.8, geschikt gemaakt voor 32-bits FoxPro-omgevingen.

Het probleem dat we wilden oplossen

De applicatie had meer nodig dan een eenvoudige bestandskiezer. Gebruikers wilden documenten direct vanuit Windows Verkenner slepen, Outlook-bijlagen neerzetten, namen ter plaatse wijzigen, gekoppelde bestanden openen en eigen bedrijfslogica laten uitvoeren voordat iets werd opgeslagen. In moderne .NET- of webapplicaties is dat niet uitzonderlijk. Binnen een FoxPro-desktopomgeving vraagt het om zorgvuldig ontworpen interoperabiliteit.

Vanaf het begin golden twee harde eisen. De oplossing moest zich binnen Visual FoxPro-formulieren gedragen als een native ActiveX-component. Ook moest deze voorspelbaar blijven in een 32-bits COM-omgeving, waar installatie, registratie en betrouwbare callbacks belangrijker zijn dan nieuwe technieken op zichzelf.

De architectuur in de praktijk

De implementatie gebruikt een WinForms UserControl voor de zichtbare interface en stelt deze beschikbaar via een COM-veilige interface. In plaats van automatisch gegenereerde klasse-interfaces definieert de component expliciet een interface voor commando’s en een aparte interface voor gebeurtenissen. Dat houdt de COM-koppeling stabiel en maakt de afspraken voor FoxPro eenvoudiger te documenteren en onderhouden.

De component biedt een gerichte API om items toe te voegen, verwijderen en hernoemen, de weergave opnieuw te tekenen, kopieergedrag te wijzigen, een basismap in te stellen en FoxPro via callbacks op gebruikersacties te laten reageren.

Intern bewaart de component een lijst met bestanden in het geheugen. Elk item heeft een compact metadataobject met pad, ID, type en omschrijving. De interface gebruikt een ListView met grote pictogrammen. De commandolaag blijft eenvoudig genoeg om vanuit FoxPro via COM te gebruiken.

Waarom expliciete COM-interfaces?

COM-koppelingen worden kwetsbaar als publieke .NET-klasseonderdelen in de loop van de tijd veranderen. Daarom gebruikt de component een expliciete standaardinterface voor aanroepbare methoden en een eigen dispatch-interface voor gebeurtenissen. Dit leverde drie voordelen op:

  • Stabiele methodeafspraken voor FoxPro.
  • Vaste DISPIDs voor de afhandeling van gebeurteniscallbacks.
  • Vrijheid om de interne implementatie te verbeteren zonder de externe automation-interface te wijzigen.

Hoe de interface werkt

De zichtbare component is bewust compact: bovenaan een rij knoppen met daaronder een groot gebied om bestanden neer te zetten. De knoppen verzorgen gangbare acties zoals toevoegen, verwijderen, openen en eigenschappen bekijken. De lijst ondersteunt slepen en neerzetten, callbacks bij selectiewijzigingen, openen met dubbelklikken en rechtstreeks hernoemen.

In de praktijk bleek de weergave van pictogrammen belangrijk. De component toont niet overal hetzelfde algemene bestandspictogram, maar haalt per bestandsextensie het Windows-shellpictogram op en bewaart dit in een cache. Verschillende bestandstypen blijven herkenbaar zonder steeds hetzelfde pictogram opnieuw bij de shell op te vragen. URL’s krijgen een eigen browserpictogram, zodat links duidelijk verschillen van bestanden.

Het lastige onderdeel: slepen en neerzetten vanuit Outlook

Volgens Windows-maatstaven is slepen vanuit Verkenner eenvoudig. Vanuit Outlook niet. Wie een bijlage uit Outlook sleept, sleept vaak geen bestaand bestand op schijf, maar een virtuele bestandsbeschrijving en gegevensstromen in het geheugen, aangeboden via formaten zoals FileGroupDescriptor en FileContents.

Dat was een van de centrale technische uitdagingen: voor de gebruiker zien Outlook-gegevens eruit als bestanden, maar de component ontvangt ze niet als gewone bestanden.

Om dit goed af te handelen, verpakt de component het binnenkomende gegevensobject en zet Outlook-gegevens om naar een vorm die de rest kan verwerken. Bijlagen worden als streams uitgelezen, waar nodig naar schijf geschreven en omgezet in gewone lijstitems met een bestand erachter. Als de inhoud een URL uit Outlook is, wordt deze apart herkend en als URL-item opgeslagen, zonder deze door de bijlageverwerking te dwingen.

FoxPro laten beslissen vóór het bestand wordt geaccepteerd

Een belangrijke ontwerpkeuze was de callback BeforeFileDrop. Voordat een gesleept of gekozen bestand definitief wordt verwerkt, geeft de component een aanpasbaar parameterobject terug aan FoxPro. Daardoor kan de FoxPro-applicatie:

  • Een bestand volledig weigeren.
  • Het binnenkomende bestand hernoemen.
  • Het opslagpad wijzigen.
  • Bepalen of het bestand echt moet worden gekopieerd of alleen moet worden gekoppeld.

Deze gebeurtenis maakte van een passief interfaceonderdeel een integratiepunt dat rekening houdt met de applicatie. De bedrijfsregels bleven in FoxPro, waar ze thuishoren, terwijl de .NET-component de lastige Windows-interactie afhandelde.

BeforeFileDrop(FileInfo parameters) - AcceptFile controls whether the operation continues - FileName can be changed before storage - FilePath can be redirected to a different folder or target - CopyFile controls whether the file is physically copied or only linked

Kopieergedrag correct afhandelen

Bestandsverwerking bleek genuanceerder dan alleen wel of niet kopiëren. Slepen vanuit Verkenner, handmatig kiezen en Outlook-bijlagen neerzetten hebben verschillende uitgangspunten. Gewone bestanden kunnen al op schijf staan en rechtstreeks worden gekoppeld. Outlook-bijlagen moeten meestal vanuit een stream als echt bestand worden opgeslagen. Handmatig toevoegen lijkt meer op een bewuste importactie.

De implementatie houdt die processen gescheiden in plaats van alles door één algemene route te sturen. Dat maakt de code begrijpelijker en vermindert neveneffecten. Ook blijft ruimte voor beleid per applicatie. Sommige installaties moeten bronlocaties behouden; andere moeten elk binnenkomend bestand met een unieke naam naar een beheerde opslagmap kopiëren.

Betrouwbare COM-callbacks

COM-gebeurteniscallbacks lijken eenvoudig totdat ze in de praktijk mislukken. Een callback in FoxPro kan een fout veroorzaken, parameterwaarden weigeren of de interface in een inconsistente toestand achterlaten als de component zich niet beschermt. Daarom vangt de implementatie fouten tijdens callbacks op en behandelt deze als volwaardige foutscenario’s.

De component laat een callbackfout niet door de hele interactie heen breken, maar vangt deze op, logt diagnostische details en toont een foutmelding met handelingsperspectief. Een mislukte BeforeFileDrop-callback betekent dat het toevoegen wordt geweigerd. Dat is de juiste standaard, omdat zo geen gedeeltelijke bestandsbewerking plaatsvindt als de bedrijfslogica niet goed kon worden uitgevoerd.

Bij desktopkoppelingen via COM hoort foutafhandeling bij het API-ontwerp. De applicatie en de component moeten samen voorspelbaar met fouten omgaan.

Waarom 32-bits nog steeds belangrijk was

Moderne .NET-ontwikkeling gaat vaak standaard uit van x64. Dat kon hier niet. Visual FoxPro is een 32-bits host en de ActiveX-koppeling moet daarop aansluiten. De component wordt voor x86 gecompileerd, met 32-bits RegAsm geregistreerd en met die installatie-eisen verpakt.

Dat lijkt eenvoudig, maar werkt door van registratiedocumentatie tot probleemonderzoek. Een technisch correcte component die met het verkeerde gereedschap is geregistreerd, werkt in productie nog steeds niet. Een deel van het werk was daarom zorgen voor correcte ActiveX-registratie, inclusief markeringen die de component invoegbaar maken en registratie van de codebaselocatie.

Kleine details met veel effect

Verschillende kleinere implementatiedetails verbeterden de bruikbaarheid merkbaar:

  • Rechtstreeks labels bewerken laat gebruikers omschrijvingen aanpassen zonder het scherm te verlaten.
  • Contextmenu’s passen zich aan naargelang de gebruiker op een item of op lege ruimte rechtsklikt.
  • Dubbele bestandsnamen worden automatisch met unieke achtervoegsels opgelost.
  • De knoppenrij kan worden verborgen, zodat de component in verschillende lay-outs past.
  • Opruimlogica geeft pictogrammen, menu’s en WinForms-resources expliciet vrij om instabiliteit tijdens lange sessies te voorkomen.

Wat dit project laat zien

FileDropArea is een goed voorbeeld van waardevol werk aan bedrijfssoftware: bestaande systemen niet zomaar vervangen, maar zorgvuldig uitbreiden met moderne mogelijkheden. De uitdaging was niet op zichzelf een lijst met slepen en neerzetten bouwen. Het ging om een component die tegelijk rekening hield met FoxPro, COM, Outlook, de Windows-shell, installatiebeperkingen en gebruikersverwachtingen.

Die afwegingen passen bij het werk dat we graag doen: praktische desktopintegratie, duidelijke interfacegrenzen en gerichte modernisering die een echt werkprobleem oplost zonder het omringende systeem te ontregelen.

Wie een bestaand desktopplatform onderhoudt en modern interfacegedrag nodig heeft zonder de applicatiekern te herschrijven, ziet hier een bruikbare aanpak: plaats de lastige platformintegratie in de juiste laag, houd de externe afspraken stabiel en laat het bestaande systeem verantwoordelijk blijven voor de bedrijfsregels.

Terug naar nieuws

Meer

Gerelateerde artikelen

22 mei 2026

Hamlet: een professionele publicatie-editor voor 4D ontwikkelen

Hamlet is een van de belangrijkste ontwikkelingen in ons huidige productplan: een native editor voor opgemaakte tekst, pagina-indeling en databasepublicaties, speciaal voor 4D. Het doel is ambitieus maar helder: 4D-ontwikkelaars een volwaardige documenteditor bieden die in een 4D-formulier draait, met echte databasegegevens werkt en professionele facturen, rapporten, brieven, templates en publicaties oplevert.

Wilt u met ons samenwerken?

Neem contact op, dan bespreken we uw project.