Can I specify a relative path to a dll in the Call Library Function Dialog?

[Lee C. Smith]

It doesn't appear that I can do more than either provide the fully qualified path or just the name of the dll, but then it has to be in the system directory. I'd really like to be able to place the dll in the same directory as the accessor VIs and tell the Call Library function that the dll is in .\ or possible .\..\
This doesn't seem possible and is extremely inflexible if I'm stuck with either a fully qualified path or placing them in the system directory.

[Jim_Kring]

You should be able to put the DLL in the same directory as the VI that calls it and specify the location as the name of the DLL. This is how I do it.

[Lee C. Smith]

Thanks, Jim, that's what I thought, but haven't been able to accomplish that. If I have just the name of the DLL in the path, I get a broken arrow. The vi can't find it unless I have it in the system directory. Are there any special setting you are aware of in LabVIEW that need attention for this to work?

[Jim_Kring]

I've never liked how the CLF node's library path attribute worked. Yes it is tricky. I am not sure why you are having problems just specifying the name of the dll. This should work, and I don't know of any other "hidden" settings that will make it work. Also, there are some other things with CLF that you might find useful:

You can specify the library name as "YourLibName.*" instead of the platform specific endings of YourLibName.dll (Win) or YourLibName.so (Unix/Linux), YourLibName.shlb (Mac OS 9), or YourLibName.framework (Mac OS X). This allows you to include, in your distributable code, the shared libraries for all platforms and LabVIEW will choose the right one for the target platform.

You can also put the DLL in the root direct
ory of LabVIEW, or your built application and it will be found at load-time.

-Jim

PS - If you attach a copy, I'll see if it can load on my machine.

[Lee C. Smith]

Jim, thanks for the help. Here's one of the set I'm working on that is giving me fits. This is just the vendor-provided driver for the Tek TDS7k scope, but it show the problem I'm having with my own in-house created items. I'm sending you this one since it's freely down-loadable so I don't have to worry so much about all the proprietary issues.
I have these on a network drive that is accessible to multiple developers who can down-load it to their local for development & build. That's were the real issue comes in. The vi is hard-coded to look at the network drive, so even if the stuff is local, it access the networked dll & crashes when the network drive is unavailable.
These came from my network drive L:\instr.lib\tk
tds7k\Tktds7k.