Nieuws
FileDropArea geeft bestaande Visual FoxPro-applicaties een moderne voorziening voor het slepen en neerzetten van bestanden, Outlook-bijlagen en links, zonder de hostapplicatie te herschrijven. Het resultaat is een COM-zichtbaar ActiveX-element op .NET Framework 4.8 voor 32-bits FoxPro-omgevingen.
FileDropArea werd gebouwd om een praktisch integratieprobleem op te lossen: oudere Visual FoxPro-applicaties hadden een modern, gebruiksvriendelijk sleep-en-drop-oppervlak nodig voor bestanden, Outlook-aanhangsels en links, zonder de host-applicatiestack te schrijven. Het resultaat was een COM-zichtbare ActiveX-besturing gebouwd op .NET Framework 4.8 en verpakt voor 32-bit FoxPro-omgevingen.
De host-applicatie had meer nodig dan een eenvoudige bestandspicker. Gebruikers wilden documenten rechtstreeks uit Windows Explorer slepen, bijlagen uit Microsoft Outlook laten vallen, items inline omschrijven, gekoppelde bestanden openen en toepassings-specifieke zakelijke logica uitlokken voordat iets werd opgeslagen. In een moderne .NET of webstack is dat niet ongewoon. In een FoxPro desktopomgeving vereist het zorgvuldig interopontwerp.
Het project had vanaf het begin twee moeilijke beperkingen. Ten eerste moest de oplossing zich gedragen als een native ActiveX-controle binnen Visual FoxPro-formulieren. Ten tweede moest het voorspelbaar blijven in een 32-bit COM-wereld waar implementatie, registratie en terugroepsstabiliteit belangrijker zijn dan nieuwheid.
De implementatie maakt gebruik van een WinForms UserControl als de visuele host en onthult die controle via een COM-veilige interface. In plaats van te vertrouwen op automatische klasseninterfaces, definieert de component een expliciete commando-interface en een aparte evenementeninterface.
De bediening laat een gericht API zien: items toevoegen, items verwijderen, items omschrijven, het oppervlak opnieuw tekenen, kopieergedrag omzetten, een basis directory instellen en event callbacks verhogen naar FoxPro wanneer gebruikersacties optreden.Intern onderhoudt de bediening een in-memory lijst van bestandselementen, elk vertegenwoordigd door een compact metadata-object met een pad, ID, type en beschrijving. De gebruikersinterface wordt weergegeven met een groot-icon ListView, terwijl de commando-laag eenvoudig genoeg blijft voor FoxPro om comfortabel te consumeren via COM.
COM-interop wordt kwetsbaar wanneer publieke .NET-klassenleden in de loop van de tijd afdrijven. Om dat te voorkomen, maakt het component gebruik van een expliciete standaardinterface voor oproepelijke methoden en een speciale verzendinterface voor evenementen.
De zichtbare bediening is opzettelijk compact: een knop rij over de bovenkant en een groot drop gebied onder. De knopbalk behandelt gemeenschappelijke acties zoals toevoegen, verwijderen, openen en eigenschappen.
Een detail dat belangrijk was in het gebruik in de echte wereld was icoon rendering. De bediening toont niet alleen een generiek bestand icoon voor alles. Het extracteert shell icoons per bestand uitbreiding en caches ze, zodat verschillende bestandstypen er anders uitzien zonder herhaaldelijk op de shell voor hetzelfde icoon te slaan. URL-inbrengsten worden apart weergegeven met een speciaal browser-stijl icoon om gekoppelde inhoud visueel anders te maken dan bestandssystemitems.
Drag-and-drop van Explorer is eenvoudig volgens Windows desktop standaarden. Outlook is niet. Wanneer gebruikers bijlagen uit Outlook slepen, slepen ze vaak geen echte bestanden van de schijf. Ze slepen virtuele bestandsdescriptors en in-memory streams die worden blootgesteld via Outlook-specifieke gegevensformaten zoals FileGroupDescriptor en FileContents.
Dit was een van de centrale technische uitdagingen in het project: Outlook-gegevens lijken aan bestanden voor de gebruiker, maar komen niet als bestanden aan de bediening.Om dat schoon te beheren, wikkelt de bediening het inkomende gegevensobject en normaliseert de Outlook payload in iets wat de rest van het component kan verwerken. Bijlagen worden als streams gehaald, op de schijf geschreven wanneer nodig, en vervolgens omgezet in normale bestandsgegevens. Als de afgevallen payload eigenlijk een URL is van Outlook, herkent de bediening dat pad apart en bewaart het als een URL-item in plaats van het door de bijlagenpijpleiding te dwingen.
Een van de belangrijkste ontwerpbeslissingen was de BeforeFileDrop-oproep. In plaats van de bestandshantering stijf te maken, verhoogt de bediening een veranderlijk parameterobject terug naar FoxPro voordat een afgevallen of geselecteerd bestand wordt ingesteld. Dat stelt de FoxPro-applicatie in staat om:
Deze gebeurtenis veranderde de bediening van een passieve UI-widget in een applicatiebewust integratiepunt. Het liet de bedrijfsregels in FoxPro blijven, waar ze behoren, terwijl de .NET-leiding het moeilijke Windows-interactiewerk aanpakte.
BeforeFileDrop(FileInfo-parameters) - AcceptFile controleert of de operatie doorgaat - FileName kan worden gewijzigd voordat het wordt opgeslagen - FilePath kan worden omgeleid naar een andere map of doel - CopyFile controleert of het bestand fysiek wordt gekopieerd of alleen is gekoppeldHet beheren van bestanden bleek nuancerender dan gewoon kopiëren of niet kopiëren. Explorer druppels, handmatige bestandselectie en Outlook-aanhangsel druppels elke start van verschillende aannames. standaard bestanden kunnen al bestaan op de schijf en kunnen rechtstreeks worden verwezen naar. Outlook-aanhangsels moeten meestal worden gematerialiseerd van een stream in een echt bestand. Handmatige toevoegingsacties gedragen zich meer als een expliciete invoer actie.
De implementatie scheidt deze stromen in plaats van ze te dwingen door een enkel algemeen pad. Dat maakt de code gemakkelijker te redeneren over en vermindert de kans op bijwerkingen. Het maakt ook ruimte voor applicatie-specifieke beleid. Bijvoorbeeld, sommige implementaties willen de locatie van bronbestanden behouden, terwijl anderen willen dat elk inkomend bestand wordt gekopieerd in een beheerde opslagmap met unieke namen.
Een FoxPro-zijde-oproep kan een fout gooien, een parameterstaat afwijzen of de gastgebruikersinterface in een inconsistent moment verlaten als de besturing zich niet verdedigt.
In plaats van een oproepexceptie door de interactie te laten scheuren, vangt de bediening fouten op, registreert debug-details en toont een uitvoerbaar foutbericht. In het BeforeFileDrop-pad wordt oproepexceptie behandeld als een afgewezen toevoegingsoperatie. Dat is de juiste standaard omdat het gedeeltelijke bestandsoperaties voorkomt wanneer business logic niet met succes kon worden uitgevoerd.
In COM-gebaseerde desktop-integratie is de foutbeheersing onderdeel van het API-ontwerp.De moderne .NET-ontwikkeling neemt vaak x64 standaard aan. Dit project kon niet. Visual FoxPro is een 32-bits host, en ActiveX interoperabiliteit volgt die realiteit. De controle wordt samengesteld voor x86, geregistreerd via 32-bits RegAsm, en verpakt met dat implementatieverhaal in gedachten.
Dat klinkt eenvoudig, maar het beïnvloedt alles van registratiedocumentatie tot storingsoplossing. Een controle die technisch correct is maar is geregistreerd met de verkeerde toolchain is nog steeds gebroken in de productie. Een deel van de implementatiewerk was ervoor te zorgen dat het onderdeel zich gedroeg als een juiste ActiveX controle in het register, inclusief invoegbare control markers en codebase registratie.
Verschillende kleinere implementatiedetails hadden een buitengewone impact op de bruikbaarheid:
FileDropArea is een goed voorbeeld van het werk dat vaak het belangrijkste is in enterprise-software: geen vervanging van legacy-systemen omwille daarvan, maar zorgvuldig uitbreiden met moderne mogelijkheden. De technische uitdaging was niet het opbouwen van een sleep-en-drop-lijst afzonderlijk. Het was het opbouwen van een die FoxPro, COM, Outlook, Windows shell gedrag, implementatiebeperkingen en gebruikersverwachtingen tegelijkertijd respecteerde.
Dat is het soort engineering trade-offs waar we van genieten: praktische desktop-integratie, sterke interface grenzen en gerichte modernisering die een echt workflow probleem oplost zonder het systeem eromheen te destabiliseren.
Als u een legacy desktopplatform onderhoudt en een modern UI-gedrag nodig hebt zonder de applicatie-kern opnieuw te schrijven, laat dit project het patroon duidelijk zien: zet de moeilijke platformintegratie waar ze hoort, houd de externe contract stabiel en laat het host-systeem het eigendom van de bedrijfsregels behouden.
Meer
FoxSQL is een TCP/IP-SQL-brug voor AccountView- en Visual FoxPro-gegevens. C#-applicaties werken met vertrouwde databasebegrippen, terwijl de FoxPro-engine het werk blijft doen waarvoor hij is ontworpen.
Lees meerHoe een bonnenscanner uitgroeide van een testbaar Swift-pakket tot een privacygericht platform voor iPhone, iPad en macOS, met OCR, Core ML, CloudKit-synchronisatie, exports, trainingshulpmiddelen en productiecontroles.
Lees meerHamlet is een native editor voor rijke tekst, paginaopmaak en databasepublicaties, speciaal ontwikkeld voor 4D. Het doel: professionele documenten maken met echte databasegegevens, rechtstreeks binnen een 4D-formulier.
Lees meer
