LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Updating DLL reference

I have a DLL (written in C) and a set of accompanying .vi modules that use this DLL.

 

The DLL is a constant development with updates appearing from time to time.

To link the .vi application to the correct version of the DLL the .dll includes a version number in the name.

 

Previously we used the "Write linker info from file" method to update the DLL references in the .vi modules but now I got stuck with a strange problem:

 

In Labview 7 and 8, the Call Library function node shows the new library name but in 2009 and newer the Call Library function node still shows the old version of the DLL being used.

A closer look at the binary file shows there are two different references in the .vi file: One being a reference to the complete library path (c:\program file\my_prog\bin\dll_version2.dll) and one being the Call Library function reference (shown as dll_version1.dll:function:c).

 

Somehow this last reference is not being updated when using the "Write linker info from file" method - resulting in a broken application in LabView 2009 and newer.

 

What method could you suggest for changing the references in my modules ?
The write linker info from file method is no longer supported and Find & Replace (not available in 7.1 ?) is not a real option - I prefer something that I could automate in my build environment.

 

Regards,

 

Rob

0 Kudos
Message 1 of 4
(4,671 Views)

Hello Rob,

 

Thanks for your posting in this forum. I found some infromstion about your issue and hope that you can through your problem with that.

Here is what you need to do in order to get this to work. Open the VI in a previous version of LabVIEW (not 2010). Open the Call Library Function Node (CLFN) and select the Error Checking tab. Change from Default to Maximum. Now run the VI. You will notice that you get error 1517. Now change the calling convention from C to stdcall. You will notice that when you run the VI now you no longer get the error. So if you now open this VI in LabVIEW 2010 and change the calling convention of the CLFN from C to stdcall, it will work.
The reason that this is happening is simple. Previous to 2010 the compiler would check for these errors, and automatically make the necessary changes for you. In 2009 and newre this no longer happens.

Besides, maybe the links below would be helpful to.

http://www.ni.com/pdf/manuals/370109b.pdf

http://digital.ni.com/public.nsf/allkb/7253D2F0D91F68058625752F005AB672

http://digital.ni.com/public.nsf/allkb/6229347C7982CC81862576E30076A4AE?OpenDocument

http://zone.ni.com/devzone/cda/tut/p/id/4877

 

and for your question about the executable and DLL file you can read the link below.

http://digital.ni.com/public.nsf/allkb/862567530005F09C862565C50068363D?OpenDocument

Good luck and if you have any question please don't hesitate to ask.

 

Best regards,

 

Hossein

 

 

 

 

 

0 Kudos
Message 2 of 4
(4,635 Views)

Hello Hossein,

 

thanks for your answer, you've included some nice links that are useful.

 

The problem is a bit different than what I expect you were expecting: Somehow the name of the DLL is not updated correctly when using the "Write linked info from file" method.

When I update my DLL name to a newer value (e.g. replace MyDLLv3_1 by MyDLLv3_2) This results in the new library being used in LabVIEW 7 but versions 8 or 2009 still mention the old name.

Updating things by hand works but that's a bit of a tedious job to do on a large number of VIs.

 

I found an intermediate solution: using Find & Replace in LabView 8 I can change the reference to my DLL in all sub VIs being called.

But this is not a real solution since now only the sub-VIs being used in the current program are changed and it takes a number of manual actions - I am still looking for an automated solution that I can integrate in my build environment.

 

I have a custom program that just patches all instances of 3_1 into 3_2 in the binary file but this is a bit tricky: I might be changing things I should not touch ...

So if someone knows a safe method that can be automated I'd be happy to hear so.

 

Cheers,

 

Rob

0 Kudos
Message 3 of 4
(4,624 Views)

Hi,

 

Sorry for my delay. You could use the link below.

 

http://digital.ni.com/public.nsf/allkb/576434CD1B659EE386256F04006909AA?OpenDocument

 

Hope this helps!

Regards,

 

Hossein

0 Kudos
Message 4 of 4
(4,603 Views)