Hallo Bitte helfen Sie mir, wie kann ich dieses Problem lösen? '' Datei nicht gefunden Rsapi.dll ''
Angehängte Dateien:
-
dt8000.jpg
180 KB -
dt8000_vba.jpg
270 KB
Wenn man eine bestimmte DLL benutzt, sollte sie auf dem Rechner auch vorhanden sein.
KOUDJIL M. schrieb: > Bitte helfen Sie mir, wie kann ich dieses Problem lösen? Google nach rsapi.ddl liefert direkt als ersten Link folgende Webseite: http://www.b-kainka.de/msrwefaq.htm Vielleicht löst das ja dein Problem.
liegt sie auch im auf der Fehlermeldung angegebenen Verzeichnis und ist registriert?
Hmmm schrieb: > Wenn man eine bestimmte DLL benutzt, sollte sie auf dem Rechner auch > vorhanden sein. Ist ein wichtiger Teil aber damit läuft alleine NIX. Sie muss (wie beim Restaurantbesuch) registriert werden. Google mal "wie registrierte ich eine DLL,OCX Datei).
Schlaumaier schrieb: > Hmmm schrieb: >> Wenn man eine bestimmte DLL benutzt, sollte sie auf dem Rechner auch >> vorhanden sein. > > Ist ein wichtiger Teil aber damit läuft alleine NIX. > > Sie muss (wie beim Restaurantbesuch) registriert werden. Das ist so pauschal Unsinn. Nur bei COM-Zeug ist das tatsächlich notwendig, alle anderen müssen nur im passenden Verzeichnis liegen. Da man zu rsapi.dll nur uraltes Zeug findet, denke ich eher, dass hier versucht wird, eine 32-Bit-DLL in einer 64-Bit-Anwendung zu nutzen.
KOUDJIL M. schrieb: > Ja, ich habe ein 64-Bit-Windows 8 Entscheidend ist in diesem Fall nicht Windows, sondern das Executable, das die DLL linken will. Aber auch das wird wohl 64-Bit-Code sein, dann geht das schief.
Hmmm schrieb: > Das ist so pauschal Unsinn. Nur bei COM-Zeug ist das tatsächlich > notwendig, alle anderen müssen nur im passenden Verzeichnis liegen. Google dll registrieren windows 10 Drücken Sie die Windows-Taste + R und geben Sie cmd.exe in die Öffnen- Zeile ein. Geben Sie nun folgenden Befehl ein und drücken Sie Enter: "regsvr32 /i <DLL-Datei>". Anstelle von <DLL-Datei> geben Sie den Namen der zu registrierenden DLL-Datei ein.
http://www.digitek.com.hk/en/cpxx2.php?keyword=dt80000&x=27&y=11 das ist anscheinend der Hersteller. ELV hatte es auch mal im Programm. https://www.ittsb.eu/forum/index.php?topic=145.0 "I did some research about the "High Performance" DT80000 of Digitek, which by high proximity it uses the FS9704B that is a child of Fortune Semiconductor Corporation in Taiwan. The IC (ADC) was designed at 2004 and got some revisions up to 2007"
Beitrag "RSAPI.DLL für Excel (VBA) installieren (com Port Ansteuerun" Vielleicht steht da ja was schlaues drin.
Schlaumaier schrieb: > Hmmm schrieb: >> Das ist so pauschal Unsinn. Nur bei COM-Zeug ist das tatsächlich >> notwendig, alle anderen müssen nur im passenden Verzeichnis liegen. > > Google dll registrieren windows 10 Du wiederholst Dich. Nach dem, was man findet, ist rsapi.dll eine stinknormale DLL, keine COM-Komponente. Und bevor Du jetzt wieder etwas "Schlaues" von Dir gibst: Component Object Model, das hat nichts mit COM-Ports zu tun. Aber es gibt offenbar nur 16- und 32-Bit-Versionen davon, und daran dürfte es gerade scheitern.
Hmmm schrieb: > Aber es gibt offenbar nur 16- und 32-Bit-Versionen davon, und daran > dürfte es gerade scheitern. Ja soweit ich das auf die Schnelle herausgefunden habe, ist die in einen Buch drin. http://www.hjberndt.de/book/msrfaq.html#6 Was das Thema DLL Registrieren angeht. Ich registriere JEDE Dll erst mal wenn es passende Probleme gibt. Besonders wenn die DLL aus den Internet stammt. DANACH mache ich mir weiter Gedanken wenn das nicht funktioniert hat. Und das passiert nur in ca. 30 % aller Fälle. Allerdings habe ich starke Zweifel ob ein modernes Office-64Bit mit so 32 Bit-Dateien überhaupt umgehen kann. Leider hat der TO aber nicht gesagt ob er Win-64bit o. 32Bit hat. Ist zwar selten aber 32Bit wird offz. verkauft, wobei meist bei billigen PC's dabei gelegt. Weshalb ich wenn ich an einen PC arbeite erst mal schaue was das überhaupt für ein Windows ist. Es gibt aber unter VBA noch ein gern gemachter Fehler. Man muss externe DLL/OCX etc. EINBINDEN. Das geht unter EXTRA->Verweise. Entweder es ist in der Liste oder man kann es zur Liste hinzufügen. ABER man kann grundsätzlich JEDE DLL hinzufügen, ob man die dann ansprechen kann ist eine andere Frage. Der TO soll mal schauen ob die DLL in der Liste ist UND ein Haken hat. !!!!!
Schlaumaier schrieb: > Ich registriere JEDE Dll erst mal wenn es passende Probleme gibt. > Besonders wenn die DLL aus den Internet stammt. DLLs aus dubiosen Quellen a la "Hier gibt's die fehlende DLL" sollte man gar nicht nutzen, denn die sind nicht weniger gefährlich als EXEs. Schlaumaier schrieb: > Allerdings habe ich starke Zweifel ob ein modernes Office-64Bit mit so > 32 Bit-Dateien überhaupt umgehen kann. Wie schon gesagt: 64-Bit-Executable mit 32-Bit-DLL funktioniert nicht. Schlaumaier schrieb: > Weshalb ich wenn ich an einen PC arbeite erst mal schaue was das > überhaupt für ein Windows ist. Er hat bereits gesagt, dass es ein 64-Bit-Windows ist. Ist aber auch irrelevant, auf die Anwendung kommt es an, nicht auf das OS.
Hmmm schrieb: > Er hat bereits gesagt, dass es ein 64-Bit-Windows ist. Ist aber auch > irrelevant, auf die Anwendung kommt es an, nicht auf das OS. Falsch. Ein Win-64 kann auch 32Bit Anwendungen. Ein Win-32 kann NUR 32-Bit Anwendungen. Ach und nur so nebenbei. VBA ist eine eigenständige Anwendung. Die selbe Anwendung läuft auch auf Corel in der PRO-Edition. Und da es eine eigenständige Anwendung ist, ist es durchaus möglich das es auch 32-Bit DLL unter einen Office-64-Bit verarbeiten kann. Aber wie gesagt, sicher bin ich mir nicht.
Schlaumaier schrieb: > Hmmm schrieb: >> Er hat bereits gesagt, dass es ein 64-Bit-Windows ist. Ist aber auch >> irrelevant, auf die Anwendung kommt es an, nicht auf das OS. > > Falsch. > > Ein Win-64 kann auch 32Bit Anwendungen. > > Ein Win-32 kann NUR 32-Bit Anwendungen. Du redest schon wieder nicht zum Thema passenden Unsinn. Eine 32-Bit-DLL passt zu einer 32-Bit-Anwendung. Und zwar auch dann, wenn die 32-Bit-Anwendung auf einem 64-Bit-Windows läuft. Insofern macht es nur in der Hinsicht einen Unterschied, dass man bei einem 32-Bit-Windows diese Fehlerquelle ausschliessen könnte. Aber das hat er eben nicht.
Ich diskutieren nicht mit Leuten die nicht lesen was ich schreibe. Also lassen wir das. Meine Systeme laufen. Die meiner Freunde/Bekannten die mich seit Jahren um Hilfe bitten laufen einwandfrei. Dabei sogar 2 an die sich nicht mal die örtlichen Fachleute (mit Geschäft) ran getraut habe. Ich habe den TO gesagt was er machen soll. Das sollte in 99% aller Fälle helfen. Ober er es macht oder nicht. Naja NOCH gibt es den freien Willen.
Schlaumaier schrieb: > Meine Systeme laufen. Die meiner Freunde/Bekannten die mich seit Jahren > um Hilfe bitten laufen einwandfrei. Dabei sogar 2 an die sich nicht mal > die örtlichen Fachleute (mit Geschäft) ran getraut habe. Ohne Dir zu nahe treten zu wollen: Es fällt in nahezu allen Threads, die Du kommentierst, auf, dass Du aufgeschnapptes Halbwissen als vermeintliches Wissen herausposaunst. Es ist schön und gut, dass Deine Systeme laufen und Du auch Freunden und Bekannten helfen konntest, aber Du scheinst nicht die Möglichkeit in Betracht zu ziehen, dass hier Leute schreiben, die in der Materie weitaus tiefer drinstecken und dafür bezahlt werden, sich damit zu befassen. Es ist eine Tatsache, dass eine DLL abgesehen von Sonderfällen (s.o.) nicht registriert werden muss. Ebenso ist es eine Tatsache, dass 32-Bit-DLLs nicht mit 64-Bit-EXEs gelinkt werden können. Und letzteres dürfte hier das Problem sein, weil Microsoft schon länger standardmässig 64-Bit-Anwendungen ausliefert.
@ Hmmm, Schlaumaier (aka Kasper & Seppel) > Es fällt in vielen Threads auf, die ihr beide vollmacht, dass ihr > aufgeschnapptes Halbwissen als vermeintliches Wissen herausposaunt.
KOUDJIL M. schrieb: > Es existiert "Datei nicht gefunden" (Fehler 53) ist nicht sehr hilfreich, weil das auch ausgelöst wird, wenn eine Anhängigkeit einer DLL nicht gefunden wurde, oder aber die DLL existiert, aber eben nicht für die Architektur des ladenden Programms. Dein Programm (in RS232__DT8000.xls) deklariert in Data_Fetch.bas die Funktionsimporte für RSAPI.DLL mit "PtrSafe" - Das macht man aber nur, wenn man unter einer 64-Bit Version von VBA deklarieren will, dass die importierte Funktion 64-Bit sicher ist - ohne PtrSafe kompiliert es unter 64-Bit VBA gar nicht erst und der Compiler sagt einem dann, dass man die Funktion überprüfen und dann PtrSafe da ran schreiben soll.
1 | Declare PtrSafe Function OPENCOM Lib "C:\Windows\RSAPI.DLL" (ByVal S As String) As Integer |
Daher habe ich die starke Vermutung, dass du eine 64-Bit Version von Excel verwendest und eine sehr alte Exceldatei (die laut Metadaten 1998 von einem Heiner Szymanski erstellt wurde) angepasst hast, damit sie kompiliert. Aber, wie hier schon erläutert, kann ein 64-Bit Excel keine 32-Bit DLL laden. RSAPI.DLL ist so ein altes Ding, da gibt es sicher keine 64-Bit Version. Du wirst eine 32-Bit Version von Excel installieren müssen um sie verwenden zu können.
:
Bearbeitet durch User
Luther B. schrieb: > KOUDJIL M. schrieb: >> Es existiert > > Dein Programm (in RS232__DT8000.xls) deklariert in Data_Fetch.bas die > Funktionsimporte für RSAPI.DLL mit "PtrSafe" - Das macht man aber nur, > wenn man unter einer 64-Bit Version von VBA deklarieren will, dass die > importierte Funktion 64-Bit sicher ist - ohne PtrSafe kompiliert es > unter 64-Bit VBA gar nicht erst und der Compiler sagt einem dann, dass > man die Funktion überprüfen und dann PtrSafe da ran schreiben soll. > >
1 | > Declare PtrSafe Function OPENCOM Lib "C:\Windows\RSAPI.DLL" (ByVal S As |
2 | > String) As Integer |
3 | > |
> > Daher habe ich die starke Vermutung, dass du eine 64-Bit Version von > Excel verwendest und eine sehr alte Exceldatei (die laut Metadaten 1998 > von einem Heiner Szymanski erstellt wurde) angepasst hast, damit sie > kompiliert. Aber, wie hier schon erläutert, kann ein 64-Bit Excel keine > 32-Bit DLL laden. > > RSAPI.DLL ist so ein altes Ding, da gibt es sicher keine 64-Bit Version. > Du wirst eine 32-Bit Version von Excel installieren müssen um sie > verwenden zu können. Vielen Dank . Ich werde es versuchen
Oh Gott, das ist ja uralt. Dachte nicht, dass das noch jemand nutzt. Dazu gibt es einen Eintrag auf H.-J. Berndt Seite: Laufen die Makros in Office ab 201x und auf Windows 64-Bit? http://www.hjberndt.de/book/msrfaq.html#mso2010 Liegt Deine Version wirklich unter "C:\Windows\RSAPI.DLL" ? Ich würde mal versuchen den Pfad der DLL im VBA Code von "C:\Windows\RSAPI.DLL" auf den Absoluten Pfad deiner DLL zu ändern.
:
Bearbeitet durch User
Bei DLLs ist das wie mit Motoröl, sowas verbraucht sich halt mit der Zeit.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.