Call library function not finding DLL in directory where my LLBs are

Question

I am using LabVIEW 8.6.  I have a set of VIs in several LLBs.  All the LLBs are in one directory.  Most of my VIs are wrappers for the functions in one DLL.  I was told to put my DLL in the directory where the LLBs are, and supposedly this is how the previous programmer worked (using an earlier version of LabView). 
In the Call Library configuration, I have specified <dllname>.dll without a path.  (This is how we want it as our VIs are an API which other programmers will integrate, so I don't know where they will put things and I can't use any absolute paths).
When I load the VIs in LabVIEW, LabVIEW can't find the DLL and asks me to located it.  It is right there in the directory with the LLBs and when I double click on it everything works fine.  However my absolute path to the DLL now appears in the Call library configuration, and we don't want that.
Does anyone know how to make this work?  I would assume that the location of the VIs (or LLBs, in this case) would be the current directory and thus Windows would look there for the DLL.  However, it seems that this is not the case (at least, in the current version of LabVIEW).
Thank you.
Batya
Solved!
Go to Solution.

Answer 1

rolfk wrote:
Well somebody using your library should not have to dig into your VIs and do all this on his own. Instead your library should wrap that and hide the troubles of this entirely.
 That is EXACTLY what I want to do.
The error cluster was added when the dynamic path option was added. It is not useful to hide that error output so it is always there. Together with the dynamic path there was improved error handling added to the CLN. One of them is that the level of error checking during the function call (exception handling) can be specified. I would assume that some of those options can generate an error code instead of popping up a dialog as they did before and for that the error code output can be useful even in the static call case.
As to what you want to do, I would long ago
I would long ago have done a lot of things differently on this project -- but no one asked me then :-)  (Good thing it wasn't me, or maybe I'd have taken offense ;-)  )
have handled that with a wrapper DLL that has basically the same functions as your other DLLs and some initiliasation function that returns a pointer to a function dispatch structure based on the actual DLL you want to call.
OK, I am getting the feeling that this will be a brilliant and elegant solution when I fully understand it.  I understand what a wrapper DLL is.  But do you mean that each version of my product would include a different wrapper DLL (with the same name so that CLN would always work), or the same one and it would somehow be told which actual DLL I want to call?  Who would decide which DLL, the VI or the wrapper DLL?
By a function dispatch structure do you mean a table of function pointers gotten by GetProcAddress, one such entry for each function?
Quite like what an object oriented function dispatch table is. Then when initilising your interface you call that initialise function and specify the interface/device type you want to use and after that all the other functions take one additional function dispatch pointer parameter as first parameter in addition to the parameters the actual function has. This function dispatch pointer would be just a pointer to a structure containing the table of function pointers for that interface and for the sake of LabVIEW would be simply a pointer sized integer.
The wrapper function then verifies the function dispatch structure pointer for validity and calls the actual function with the remaining parameters.
I think I understand what the wrapper functions need to do.  But I am missing some pieces for the initialize function.  It would have to do LoadLibrary and lots of GetProcAddresses -- that much I get.  But I still don't understand who decides which DLL.  Maybe you mean that the wrapper DLL's initialize function will get the DLL name and path from the registry, load it, try a different path if the load fails, etc.  Is that what you mean?  That could work very nicely.   But from where would it get the registry key?  From the VI?  This is the part that would clearly be different for each product.  I suppose that you had something in mind when you described your solution. 
This is some C programming
Great!  That's what I do for a living.  At least I know how to do that!  Hey, I should have thought of this idea! 
and might require some planning and desigining of the different interfaces to facilitate this kind of dispatch technique but it will for sure pay of in the long run, and make your library even usable in earlier LabVIEW versions, as well as VB etc. without tricky dynamic loading in the high level programming environment.
Ah, see how much I don't know in LabVIEW?  I didn't know this was a new feature...
Thank you for the great idea.
Batya Perlman