Jump to content

Specifying .dll path at runtime in "Call Library Function"


Recommended Posts

Hi there everyone,

First posting, so here goes...

Does anyone know if there's a workaround the normal "Call Library Function" such that you can pass in a path/string to the .dll file you want to call, instead of it being fixed in the Properties page at design time?

I've a need to read a customer specific path from a registry key (which I can do no problems), and then call a standard set of functions in a .dll file this the key points to. The function names can be specified at design time in the properies page.

The reason behind the required is that there will be a number of these keys all pointing to "different" .dlls. All of which have the same functions/data types, although they do different things going on behind the scenes. Obviously, all of the dll's (should) have been written to the same function/parameter standards, so there should be no problem in interfacing to different copies of the "same" thing.

Any help appreciated!

Cheers,

ChrisC.

Link to comment

I'm pretty sure there's not a way to do this in LabVIEW. I don't know about version 8.

As painful as it sounds, what I would be prone to do if I were you would be to make your own wrapper DLL. Depending on how many different calls you were making (how many different interfaces you were attempting to import into LabVIEW) it could be simple or really time-consuming.

At any rate, you could just pass the dynamic DLL path to your static DLL and let it make the calls and return data... that way your LabVIEW Call Library Function node would have a fixed path to your DLL, but it would call the other DLL's and get data from different places.

Link to comment

Here is a way that should work, although I have not tried it:

Create a VI named something like "DLL_Wrapper.vi" with a Call Library Function that calls the DLL. However, create a copy of one of the DLLs and name it something like "Dynamic_DLL.dll" and have DLL_Wrapper.vi call Dynamic_DLL.dll. At run-time, copy and rename the specific DLL you wish call as Dynamic_DLL.dll and place it in the same directory as DLL_Wrapper.vi (or the location where DLL_Wrapper.vi expects to find it). Then, open a reference to DLL_Wrapper.vi which will load it and Dynamic_DLL.dll into memory. Use Call By Reference to call DLL_Wrapper.vi and thus Dynamic_DLL.dll. Then close the reference to DLL_Wrapper.vi, which will unload DLL_Wrapper.vi and Dynamic.dll from memory. Repeat, as needed.

Link to comment
Hi there everyone,

First posting, so here goes...

Does anyone know if there's a workaround the normal "Call Library Function" such that you can pass in a path/string to the .dll file you want to call, instead of it being fixed in the Properties page at design time?

I've a need to read a customer specific path from a registry key (which I can do no problems), and then call a standard set of functions in a .dll file this the key points to. The function names can be specified at design time in the properies page.

The reason behind the required is that there will be a number of these keys all pointing to "different" .dlls. All of which have the same functions/data types, although they do different things going on behind the scenes. Obviously, all of the dll's (should) have been written to the same function/parameter standards, so there should be no problem in interfacing to different copies of the "same" thing.

Well with the much talked about scripting there is a way to change the path, but there is a big BUT or better two. You can only invoke scripting operations on VIs which are in edit mode so your VI containing the Call Library Node would need to be loaded dynamically, you would have to walk the VI object tree for the Call Library Node primitive change its path and then reopen it as strict type def again dynamically to invoke it with the Call by Reference Node. All in all a lot of work and in LAbVIEW 8 scripting is not available anymore without a license for this feature.

Rolf Kalbermatter

Link to comment
Jim....

I like your solution. It will only work if you're calling one DLL at a time though right? I don't think it was a requirement to call more than one at the same time but I was just thinking things through.

Correct, you can only call one DLL at a time this way. Rolf's suggestion (to write the linker info to the VI and change the called DLL) was also on my mind but this method requires 1) That you be in the development environment, 2) have access to scripting, and 3) understand what linker info is. So, I avoided that solution.

Actually, maybe there is another way to do it. I think that the link to the DLL path is stored in clear text, within the VI (binary) file. If you used a fixed width path like "My_Dynamic_DLL_NNN.dll" you could do a character replacement of the VI's binary information -- for example "My_Dynamic_DLL_001.dll", "My_Dynamic_DLL_002.dll", etc. This could allow you to open multiple instances of the DLL.

Link to comment
All in all a lot of work and in LAbVIEW 8 scripting is not available anymore without a license for this feature.
Rolf,

Perhaps I missed a discussion somewhere - has there been an announcement from NI about formally supporting scripting and a licensing scheme for its use? I'm not doubting you, of all the people on LAVA or Info-LV (outside of NI) you would probably know.

Just wondering.

With best regards,

Dave

Edit: Just saw your other post in the scripting forum. Can you tell me more particulars about licensing under LV8? I've only partially switched to the release version of 8 (still waiting for the updated VLM and a new license file) so I haven't explored the issue yet.

Link to comment
Perhaps I missed a discussion somewhere - has there been an announcement from NI about formally supporting scripting and a licensing scheme for its use? I'm not doubting you, of all the people on LAVA or Info-LV (outside of NI) you would probably know.

David,

No official announcement has been made. But Brian seems to have talked to someone from NI who did confirm my suspisions. I for myself have come to that conclusion after having searched for the new INI key to enable scripting but I instead came across some routines that also control the other licensing in LabVIEW.

Rolf Kalbermatter

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.