Sådan rettes OLE fejl 8004013F på Linux

Hvis du forsøger at køre enhver form for database eller makro i et vinbaseret miljø på enhver form for GNU / Linux-implementering, kan du muligvis opleve en slags fejlmeddelelse. På et eller andet tidspunkt under programflowet kan du i sidste ende se en OLE-fejl 8004013F boks. Dit script ophører derefter med det samme. Hvis dette skulle ske, mangler du mere end sandsynligt et bibliotek, som dit script skal køre. I en indbygget Windows-klient bruges disse biblioteker til at matche objekter inde i filer med deres overordnede vært. Linux har ikke denne mulighed, da hvert program, der kører på en X Server, styrer tingene på sin egen måde.

Under et oprindeligt Microsoft Windows-miljø kan Delphi bruge en lille smule kode til at åbne Excel. Hvis du ville have en indlejret og sammenkædet forekomst af Excel til at arbejde med forskellige objekter, så har du muligvis brugt det eclApp: = CreateOleObject (‘Excel.Application’); for at gøre det. Inde i Linux har du måske endda forsøgt at bruge OpenOffice på denne måde. Skulle du finde Delphi kaste den frygtede 8004013F fejl på dig, efter at du har forsøgt at oprette et OLE-objekt med en forekomst af eclApp: = CreateOleObject (‘com.sun.star.ServiceManager’); uddrag, så lider du sandsynligvis af det samme afhængighedsproblem. Se først over din kode for eventuelle stavefejl. Dette er de mest almindelige årsager til fejl, selv før afhængigheder er involveret. Når du er sikker på at du har skrevet alt korrekt, og derefter kan du fortsætte med at gendanne de nødvendige biblioteker.

Nødvendige OLE-biblioteker

Du kan også opleve den samme fejl, hvis du forsøgte at bruge et Windows-arrangørprogram kaldet keynote-nf, og hvis det er tilfældet, kan du bruge den samme proces til at afhjælpe det. Keynote.exe-filen leveres ikke med et installationsprogram, så det er almindeligt at kopiere den til biblioteket Programfiler. Mens det muligvis kører, kan du opleve enten den ovennævnte 8004013F-fejl eller en anden 80004001-undtagelse. I begge tilfælde skal du oprette en mappe inde i programfiler med enten kommandoen mkdir eller din grafiske filhåndtering. Kald det KeyNote-NF, og flyt keynote.exe binært til det.

Hvis du har adgang til en Windows XP-, Vista-, 7, 8, 8.1 eller 10-partition, kan du prøve at kopiere msftedit.dll-filen fra C: Windows system32 til det KeyNote-NF-bibliotek, du oprettede. Du skal også kopiere msls31.dll-filen. Du kan også erhverve begge disse fra en installations-CD, men du bliver nødt til at bruge kommandoen udvid for at pumpe dem op. I begge tilfælde skal du køre programmet, og du skal finde ud af, at det fungerer fint.

Thunar, Nautilus og andre lignende filadministratorer identificerer keynote.exe som en DOS-eksekverbar fil, som du sikkert kan ignorere. Du skal bare køre det som du tidligere havde gjort. Når du højreklikker for at få adgang til en genvejsmenu, får du muligvis en mulighed, der opfordrer dig til at køre den under Vin. Vælg denne mulighed for at starte den. At køre programmet fra terminalen i stedet giver dig mulighed for at se eventuelle fejlmeddelelser, der muligvis hæver hovedet i processen. I nogle tilfælde får du faktisk en advarsel om et andet filnavn end enten msftedit.dll eller msls31.dll, som du i stedet skal erhverve. Ligesom et Unix-afhængigheds kaninhul kan du teoretisk bruge lidt tid på at erhverve en mappe fuld af forskellige filer.

Når du har det samme problem med Excel- eller Delphi-kode, skal du navigere til den mappe, der indeholder den eksekverbare fil, du forsøger at køre, og placere de to dynamisk sammenkædede biblioteksfiler i den mappe. Du kan give Vin total adgang til disse ved at indsætte dem ~ / .wine / drive_c / Windows / system32 også, men dette overskriver måske nogle af de filer, som Wine installerer som standard.

Da disse DLL'er på nogle måder er overlegne de open source-løsninger, som Wine bruger, kan de også hjælpe med at linke objekter i andre programmer, du muligvis kører, men mange brugere kan ikke lide tanken om at forurene deres Linux-installation med lukket kilde filer. At placere dem kun i de mapper, som dine programmer rent faktisk bruger, er den bedste måde at løse dette problem på. Du kan endda oprette mapper til faktiske Windows-tilbehør, du har kopieret fra en anden partition. For eksempel oplever nogle brugere denne slags problemer, hvis de bruger et bash-script eller Delphi-kode til at starte traditionelle WordPad-forekomster. Vin har muligvis installeret sin egen version af write.exe, men der er intet, der forhindrer dig i at oprette en mappe i “~ / .Wine / drive_c / Program Files /” og placere write.exe, msftedit.dll og msls31.dll til det, og henviser derefter til den mappe med din kode. Da Vin indeholder en primitiv version af cmd-tolk fra Microsoft Windows NT, kan du også henvise til disse programmer i batch-scriptfiler, hvis du foretrækker det. Sørg for at forord disse med @ECHO OFF, ellers vises hver kommando, som om du har skrevet den på en kommandolinje og derefter skubbet enter for at udføre den ene efter den anden.

Mange sider på Internettet tilbyder DLL-objekter til download, og det kan være fristende at gå med et af disse arkiver, hvis du ikke har en Windows-installation på en anden partition. Selvom de virkelig kan være helt praktiske, skal du sørge for at udføre en malware-scanning på msftedit.dll og msls31.dll, hvis du er tvunget til at erhverve dem på denne måde. Du skal ikke behandle disse arkiver på samme måde, som du behandler de officielle, der er sponsoreret af projekterne Ubuntu, Debian og Fedora.

Husk også på, at hvis du er tvunget til at erhverve dem på denne måde, kan det medføre licensproblemer, hvis du omdistribuerer din kode. Installer ikke nogen eksekverbar, som et sådant arkiv beder om, da disse eksekverbare filer oftere end ikke er en form for adware designet til at påvirke brugere af faktiske officielle Microsoft Windows-softwaremiljøer. Det samme gælder for ethvert tilfælde, hvor du måske har været forpligtet til at downloade et antal forskellige biblioteker uden for disse to, da de kan blive bytte for den samme slags adware-invasion.