Funktion in DLL exportieren und in Excel nutzen
-
Und ist DllInstall() nicht genau was du willst?
-
Laut MSDN scheint das wie DllRegisterServer zu sein, nur dass man da noch Parameter übergeben kann. Mehr Infos finde ich nicht wirklich. Auch Beispiel-Implementationen finde ich kaum. Alles nicht so einfach...
-
Versuch einfach mal
regsvr32 /i deinedll.dll
-
Dafür müsste ich erstmal DLLInstall aus meiner DLL exportieren. Und da habe ich ja das gleiche Problem wie bei DLLRegisterService. Ich hab's natürlich trotzdem ausprobiert und kriege die entsprechende Fehlermeldung, dass der Einstiegspunkt nicht gefunden wurde.
-
Ah verdammt, ich dachte DllInstall ist eine Systemfunktion. Lesen müsste man können
-
Man muss halt selbst den Registrierungscode und so schreiben, schade. Dabei will ich doch gar keine Funktionen usw. registrieren, sondern einfach nur die DLL allgemein verfügbar machen. Gibt es ja nicht so was wie ne PATH-Angabe? Einfach in system32 kopieren reicht leider nich
-
Eisflamme schrieb:
Gibt es ja nicht so was wie ne PATH-Angabe? Einfach in system32 kopieren reicht leider nich
Wenn der Ordner in dem die dll liegt in der PATH Variable eingetragen ist findet das System sie auf jeden Fall. Wenn Excel sie dann nicht findet kann das nur bedeuten dass es explizit in irgendwelchen anderen Pfaden sucht. In System32 reinkopieren war nie und ist keine gute Idee. Der Ordner heißt nicht umsonst System32...
-
Mir doch egal, was soll das denn schaden? Aber es klappt nicht, obwohl system32 im PATH liegt
-
64bit System? Excel ist eine 32bit Anwendung und System32 ist der falsche Ort für 32bit dlls auf einem 64bit Windows. Unter Windows Vista/7 ist der Ordner den du suchst SysWOW64, unter XP wars iirc System32\WoW64. Ich hoffe du gehst mit diesem Wissen nun verantwortungsvoll um und verwendest es nicht dazu die Systemordner mit irgendwelchen dlls vollzuspammen
-
Juchu, es geht
Aber jetzt Mal ernsthaft: Wieso sollte ich meinen Benutzern nicht dazu raten, die DLL dort hinzukopieren?
-
Eisflamme schrieb:
Aber jetzt Mal ernsthaft: Wieso sollte ich meinen Benutzern nicht dazu raten, die DLL dort hinzukopieren?
Wieso solltest du deinen Benutzern nicht auch dazu raten sämtliche Dateien die sie so erzeugen auf dem Desktop zu speichern!? Immerhin hat man da immer sofort Zugriff auf alles...
Systemordner sind für Systemdateien gedacht. Irgendwelche dlls von Irgendjemandem sind keine Systemdateien wenn du mich fragst und haben dort daher einfach absolut nix verloren.
Außerdem: Um etwas in einen Systemordner reinzukopieren benötigt man Administratorrechte. Das ist nicht umsonst so und davon auszugehen dass sowieso Jeder Admin-Rechte hat ist imo keine gute Idee.
-
Ich leg da immer alles Temporäre ab, find ich super. Und meine DLL ist ja so super, dass man die auch nie wieder löschen möchte -> system32
Einziger Nachteil ist, dass man bei Neuinstallation des System sicherlich nicht an die Sicherung dieser fantastischen DLL denkt.
Im Endeffekt ist doch Excel Schuld. Würd das einfach im gleichen Verzeichnis nach DLLs suchen, wär das alles kein Problem, aber neeein...
-
Du könntest auch versuchen rauszufinden warum Excel die dll nicht findet. Ich finde es jedenfalls höchst merkwürdig dass es im SysWow64 geht aber mit PATH nicht. PATH sollte eigentlich praktisch immer durchsucht werden, außer wenn Excel das irgendwie explizit unterbindet. Bist du dir sicher dass du dich nicht einfach nur vertippt oder ein ; vergessen hast? Außerdem musst du Excel wohl neu starten nachdem damit es die Änderungen an PATH mitbekommt.
-
dot schrieb:
64bit System? Excel ist eine 32bit Anwendung und System32 ist der falsche Ort für 32bit dlls auf einem 64bit Windows.
Excel gibt es auch als 64bit Anwendung.
dot schrieb:
Ich hoffe du gehst mit diesem Wissen nun verantwortungsvoll um und verwendest es nicht dazu die Systemordner mit irgendwelchen dlls vollzuspammen
Dem kann ich mich auch nur anschließen.
Das Verzeichnis spielt sowieso bei einem COM Objekt keinerlei Rolle.
-
Aber nun, wo es drin ist, kann ich es von überall benutzen, das ist schon ein Vorteil.
Was ist denn jetzt konkret der Nachteil daran?
-
Eisflamme schrieb:
Aber nun, wo es drin ist, kann ich es von überall benutzen, das ist schon ein Vorteil.
Wie ich es versteheist es ein COM-Addin. Du kannst es sowieso überall benutzen, denn das Laden wird direkt durch COM ausgelöst und der Pfad steht sowieso explizit in der Registry.
Wo siehst Du also einen Vorteil?
-
Und wenn es kein COM-Addin ist dann sollte es PATH auch tun...
Martin Richter schrieb:
Excel gibt es auch als 64bit Anwendung.
Wusst ich gar nicht, bei mir isses 32bit, ging davon aus dass das wohl wie mit Visual Studio sein würde wos atm einfach nur 32bit gibt...
-
Also ich habe die DLL und meine Excel-Moduldatei, das möchte ich dem Benutzer übergeben. Aber so wie es zur Zeit ist, muss der Benutzer im VBA-Code noch den Pfad der DLL ändern, weil Excel die sonst nicht findet. Das ist umständlich und nicht sehr benutzerfreundlich.
Würde ich das in System32 / WOW64 verschieben (etwa durch eine install.bat), wäre der Aufwand geringer, denn dann beschwert sich Excel nicht, wieso auch immer.
-
Excel sucht immer in folgenden Verzeichnissen:
Verzeichnis der XLS-File
Sysii (<- ich darf das sagen, kenn's persönlich) Verzeichniss "Windowsverzeichnis"\System32
Im "Windowsverzeichnis" (z.B. C:\Windows)
und in der mit PATH Umgebungsvariablen angegebenen Verzeichnissen.Wenn aber das Verzeichniss vom Anwender angegeben werden kann (mit enrsprechendem Dialog) geht auch ditte:
Dim hModule As Long hModule=LoadLibrary("C:\Pfad\Meinedll.DLL")Endung (".DLL") weglassen funktioniert nur bei System DLL's.
Grützi
