+- LabVIEWForum.de (https://www.labviewforum.de)
+-- Forum: LabVIEW (/Forum-LabVIEW)
+--- Forum: LabVIEW Allgemein (/Forum-LabVIEW-Allgemein)
+---- Forum: DLL & externer Code (/Forum-DLL-externer-Code)
+---- Thema: relativ Pfad für Call Library Function (/Thread-relativ-Pfad-fuer-Call-Library-Function)
relativ Pfad für Call Library Function - GT123 - 02.11.2012 09:59
Hallo,
ich möchte eine Call Library Function in mein Projekt einbinden.
Da stellt sich mir die Frage wie das mit dem Pfad ist. Denn in den Einstellungen der Call Library Function
ist es ein absolut Pfad. Da ich mit installer und builds arbeite, also mit Applikationspfaden muss ich dies doch irgendwie der Call Library Function mitteilen?
Oder wird das von LV automatisch erkannt?
MfG
RE: relativ Pfad für Call Library Function - jg - 02.11.2012 17:23
LabVIEW sucht zum Aufruf von DLLs eine Reihe von Standardpfaden ab. Dazu gehört u.a. das Windows-System-Verzeichnis, das Verzeichnis der Exe und noch einiges anderes.
Das kann dir aber doch eigentlich egal sein. Laut deinem Profil arbeitest du mit LabVIEW 2010, da kannst du den Aufrufpfad am DLL-Knoten direkt angeben.
Gruß, Jens
RE: relativ Pfad für Call Library Function - rolfk - 05.11.2012 01:00
(02.11.2012 09:59 )GT123 schrieb: Hallo,
ich möchte eine Call Library Function in mein Projekt einbinden.
Da stellt sich mir die Frage wie das mit dem Pfad ist. Denn in den Einstellungen der Call Library Function
ist es ein absolut Pfad. Da ich mit installer und builds arbeite, also mit Applikationspfaden muss ich dies doch irgendwie der Call Library Function mitteilen?
Oder wird das von LV automatisch erkannt?
MfG
Also Jens ist soweit korrekt. Wenn Du einen absoluten Path in der Konfiguration angibst, merkt LabVIEW sich den aber beim builden der Applikation wird die DLL mitkopiert und in einem Directory innerhalb des Applikationsdirectories abgespeichert (default data). Zudem passt LabVIEW den Pfad zu dieser DLL in allen VIs an, die diese DLL referenzieren.
Das sollte man allerdings nur für Custom DLLs so tun. Für System DLLs (alles was in Windows und in System(32)) ist sollte man NUR den DLL Namen ohne irgendwelche Pfadangaben einführen. LabVIEW sucht dann die DLL in den von Jens angegebenen Orten und updated den Pfad im Library Path control, speichert aber nur wirklich den DLL Namen mit dem VI. Diese DLLs werden beim Builden nicht mitkopiert. Das ist gut so, denn alle DLLs die in Windows und Ssytem32 directory liegen sind entweder Windows System DLLs oder DLLs die mit einem seperaten Installer installiert wurden/werden sollten.
Wenn Du den absoluten Pfad zu diesen DLLs einführst denkt LabVIEW dass es eine applikationsprivate DLL ist und kopiert sie in die built Application. Das führt im Falle der meisten Windows System DLLs zu sehr komischem bis katastrophalen Verhalten da Windows DLLs auch mehrmals in den Speicher lädt wenn sie von einer Applikation von verschiedenen Lokationen angefragt werden und dann die ganze Resourcenverwaltung von Windows durcheinander gerät, da diese zwei selben DLLs versuchen Objekte in ihrem jeweiligen eigenen Heap anzulegen und Referenzen (Handles) zu diesen Objekten im der jeweils anderen DLL absolut keine Gültigkeit haben.
RE: relativ Pfad für Call Library Function - GT123 - 05.11.2012 06:39
Hallo jg und rolfk,
vielen Dank für eure Hilfe.
Ich habe nun die Aktivierung für die externe Pfadvergabe gefunden :-) yeah
Wenn ich es richtig verstanden habe (keine System dll) muss ich ja gar kein Pfad mehr korrigieren.
LV legt es in data ab, richtig.
Ich Frage mich ob LV es dort auch hoffentlich als erstes dort sucht ohne lange Wartezeit, oder?
RE: relativ Pfad für Call Library Function - rolfk - 05.11.2012 16:18
(05.11.2012 06:39 )GT123 schrieb: Hallo jg und rolfk,
vielen Dank für eure Hilfe.
Ich habe nun die Aktivierung für die externe Pfadvergabe gefunden :-) yeah
Wenn ich es richtig verstanden habe (keine System dll) muss ich ja gar kein Pfad mehr korrigieren.
LV legt es in data ab, richtig.
Ich Frage mich ob LV es dort auch hoffentlich als erstes dort sucht ohne lange Wartezeit, oder?
Ja!