(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.
/
relativ Pfad für Call Library Function
