Reusing VIs with call library, same function, and different DLL

[BPerlman]

We currently have several related libraries of VIs which are mostly wrappers for DLL code using the call library node.   Most of the VIs are identical between the libraries, and we therefore use the exact same VIs for both, to simplify both creating new libraries and maintaining existing ones.

The main difference between the libraries, with the exception of a handful of VIs, is that the underlying DLL is different (but with the same interface). 

So far the only way we have figured out to make this work is to call all the DLLs by the same name. 

We have found this to be problematic for many reasons.

What we would really like is to use the same VIs but have some way to specify different DLL names without duplicating and modifying the VIs -- something like using an environment variable in Windows.  That is, that the call library node wouldn't have the actual DLL name -- it would have some kind of variable which is specified globally or retrieved from somewhere central.

Is there any way to do this?

Thank you.

Batya

[Denver_]

Hi,

I'm assuming that you are using the call library function node to interface with the dll. In this case you can specify the path of the dll on the block diagram ( this option is available

when you configure the call library function node). You can then pass the name / path of the dll programatically depending on the requirement.

 

I've not actually tried this. So i'm not sure if this will work. 

[BPerlman]

I have seen the option to specify the path on the block diagram but I don't see how this really helps us -- I don't think we want to require our customers to wire up an input with the DLL path and name every time they use one of our VIs.  Especially since we have an existing customer base and can't exactly require them to redo their whole application when they take the next release of our library!

What I really want is to make it transparent to the caller; something we can specify in a setting or something globally.

Thank you.

Batya

[Dennis_Knutson]

I don't understand how your question has not been answered. You wanted a means of storing the dll path in some central location. You've got it. You can save the path in the windows registry or ini file. Read it and pass the path to the Call Library Function Node. There is no requirement that you make the path a control.

There are built-in functions for reading the registry and an ini file.

[BPerlman]

Dennis Knutson,

Thank you for giving me some of the information I need to find a solution to the problem.

I would have appreciated a bit more detail since I clearly am not familiar with the functions you are talking about (but I'm sure I can figure it out).

I also would have appreciated having your answer worded without the implied put down.  Obviously I did not have enough information to understand the answer, or I would not have kept asking.  If you don't understand how my question wasn't answered, then you don't understand that not everyone knows as much as you -- and not everyone has to.  Maybe try to remember what it was like not to know all the answers.  I am also in a complete vacuum other than the forum -- this is not a LabVIEW shop and no one here knows anything about it.  I did the LabView Basics I course and am considered the local expert (ha ha ha).  So lay off.

I also tend to be hesitant to accept as an answer a suggestion of "try this, it might work".  I prefer someone who knows the answer and knows how it works.

Have a good day and thank you everyone for your help.

Batya

[BPerlman]

OK, I am doing as suggested and reading the DLL name and path from the registry.  For my usual situation it works fine. 

However, there is one case which is not covered -- and I am getting results which I completely do not understand. 

When not using the "specify path on diagram" option, you can specify the path in the configure dialog box, but if the DLL is not found there the path is stripped off the DLL name and just the DLL name is passed to Windows, which looks in the standard Windows search path (and, in the case I am trying to handle, finds the DLL in the winsysdir).

I was hoping to combine the two features (specify path on diagram and finding the DLL in the search path if it is not found where specified).  I did not know if it would work, so I tried it as an experiment.  What I found is very puzzling.  It seems to load the DLL (and tells me the DLL is loaded from a new path) when I open the VI.  Indeed, if I then try to delete or overwrite the copy of the DLL in the windows system directory I get an error from Windows that it is in use.  So it looks as if it has properly loaded the DLL from there.  I was happy -- maybe I'll have a beautiful solution!

However, when I run the VI, it looks like it is running properly, and the call library function returns 0 (which is the value I expect).  However, if I use that value (which is supposed to be a handle) as input to another VI it is clear that something went wrong.  So I passed an incorrect input to my VI and ran it.  I did not get the expected error return -- it again looked as though it ran properly and succeeded.

I did some other debug which I'll skip here....then made a version of the DLL in which that function ALWAYS returns an error, right away when called.  Still, the call library function node returns zero as if everything had gone fine; but now zero is NOT an expected value.

So it looks as if it is somehow loading the DLL and not calling it properly, but failing to inform me of the matter.

I had a similar effect in another situation.  In that situation the called function was "crashing" (accessing a bad pointer).  But here I am not managing to execute the first line of code in the function.  Also, in this case, the same VI, same input, and same DLL work fine when the DLL is "found" differently (either in the expected directory or with the path not specified on the diagram).

Any one out there who can help me?  (Please keep in mind while answering that I am a newbie and won't necessarily understand the implications of an answer with some of the information implied.  I'll get there 🙂 )

Thank you.

Batya Perlman