DLL findet andere DLL und ini File nicht. Wie einbinden?

(22.09.2015 12:32 )galilio schrieb:  

(22.09.2015 12:10 )jg schrieb:  zu 2) Wieso willst du LabVIEW sagen, wie die file.ini aufzurufen ist? Laut deiner Frage liest deine DLL diese Ini-Datei!

Gruß, Jens

Wie ist das aufgerufen wird, geschieht es schon in der DLL selber.
LabVIEW findet aber die ini file leider nicht.
Die ini File ist auch in der gleischen Ordner wo die DLL auch sind.

LabVIEW findet die INI file nicht weil es gar nicht danach sucht. Deine DLL tut das und wie sie das tut kann LabVIEW nicht wissen und sollte es auch nicht zu wissen versuchen. LabVIEW weiss nur dass DLL XYZ.DLL von einer Call Library Node angesprochen wird. Von dieser DLL weiss es auch den Pfad. Dann sagt es Windows, bitte lade mir diese DLL und wartet dann einfach bis Windows eine Antwort gibt, entweder: Alles in Ordnung die DLL ist jetzt verfügbar und Du kannst sie aufrufen oder aber, sorry etwas ging schief, Pech gehabt, die DLL konnte nicht geladen werden.
LabVIEW kommt beim ganzen Laden der DLL und etwaiger weiterer DLLs die diese DLL haben möchte nicht mehr ins Spiel.

Zu 3 und 4 das sind die Directories C:\Windows und C:\Windows\System32 wobei Du mit den exakten Namen wieder aufpassen musst. Windows kann während der Installation ein anderer OS-Ordner vorgegeben werden. C:\Windows ist der Default aber das kann auch anders heissen und bei Netzklients sogar auf einem anderen Laufwerk sein. System32 ist auch so eine Sache. Auf einem 32 Bit Windows System ist es System32, aber auf einem 64 Bit Windows System ist es SysWOW64 für eine 32 Bit Applikation und System32 für eine 64 Bit Applikation. Schaust Du noch durch?

Willkürliche DLLs in eines dieser Verzeichnisse zu kopieren ist eine Garantie für Kopfschmerzen und Haarausfall zu einem späteren Zeitpunkt, also simpelweg nicht zu empfehlen. Das Beste ist eigentlich um die DLLs in dasselbe Verzeichnis zu kopieren dann Dein LabVIEW Projekt File. Das funktioniert meistens gut, da LabVIEW Windows dieses Directory als extra Suchoption unterzujubeln versucht. Leider kann das aber in einzelnen Fällen schiefgehen, wenn der DLL Programmierer versuchte schlauer dann Windows zu sein. Wenn alle Stricke reissen bleibt nur, um entweder die DLLs in das LabVIEW Verzeichnis zu kopieren oder Dich mit Deiner PATH Umgebungsvariablen etwas freundlicher zu unterhalten, um dort das Verzeichnis wo alle Deine DLLs liegen einzutragen.

Wie Deine DLL das INI File zu finden versucht kann weder Windows noch LabVIEW wissen. Das weiss nur der Programmierer der DLL und der ist dann auch die einzige Person die abschliessend sagen kann wie das gehen sollte. Wenn er es nicht kann, dann würde ich sowieso kein Vertrauen in die DLL haben.

Und wie stellst Du fest dass Variante 1) nicht funktioniert? Du musst natürlich die DLL(s) selber irgendwie laden bevor Du auch nur ein einziges VI lädst, dass eine Call Library Node enthält das Deine andere DLL laden möchte. Denn Call Library Nodes laden die DLL wenn das entsprechende VI geladen wird, aber Dein Programm kann erst etwas selber zu laden versuchen (etwa durch Aufruf von LoadLibrary()) nachdem die VIs geladen sind.

Workarounds:

1) Du partitionierst Deine Applikation in mehrere Hierarchien, eine die ein Miniprogramm started das etwa einen Splashscreen enthält und Deine sekundären DLLs zu laden versucht und danach erst das HauptVI öffnet und mit Run VI started.

2) Oder Du definierst den Library Path zu Deiner HauptDLL auf dem Diagramm statt in der Call Library Node. Dann wird die DLL erst geladen wenn die Call Library Node das erste Mal ausgeführt wird und kannst Du davor wiederum die anderen DLLs erst laden.

Persönlich würde ich zu 1) tendieren aber grundsätzlich ist die sauberere Lösung die DLLs am richtigen Ort zu haben oder die PATH Variable anzupassen.