LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

error 1003 calling dll recursively

Hi all,

 

I am trying to create an executable which calls using a 'call library function node' a dll I have created before. When I call a dll which doesn't call other dlls( recursively) it works fine. The problem come when I call a dll which calls another dll. In this case I get and error message from the error out of the call library function node like this:

 

1003 - Call Library Function Node in Untitled 3.vi<APPEND> Untitled 1.vi

 

Untlited 3 and 1 one are the startup vi of the executable and the vi that I have used to create the first level dll (untitled 3 (executable) calls---->untitled 1 (dll1) calls----> untitled 2 (dll2)). I hope you understand it.

 

The thing is when I run untitled 3 vi, without creating the executable it works fine. The error only apear when I create the executable. 


I call the dll adding the complete path in the call library function node.

 

Any advice?

 

Thank you in advance

 

Juan Luis

Message 1 of 10
(3,261 Views)

Any suggestion?

0 Kudos
Message 2 of 10
(3,234 Views)

Could you attach your code? or screen shots?

 

when do you get the error 1003? when building the executable?

 

Regards
Freelance_LV
TestAutomation Consultant
0 Kudos
Message 3 of 10
(3,227 Views)

I get the error when I run the program in .exe extension. I run it but when it calls the dll it shows that error.

 

I have done a simple program to check it. I have created  two dlls, very easy one, just returning a number. One dll call the other one and the executable call one dll ( which call the other dll)

 

the executable works but shows the error when the call dll using the error out in the 'call library function node'

 

You can find attached untitled 1.vi untitled 2.vi and untitled 3.vi . With them I create the executable (untitled 3.vi) which calls the first dll (untitled 1.vi) and the second dll which is called by the first dll (untitled 2).

 

The program is very simple, the second dll create a 77 using a constant which is passed to the first dll and this one passes again the number to the executable.

 

Thanks a lot,

 

Juan Luis

Download All
0 Kudos
Message 4 of 10
(3,222 Views)

I use a lower version of LabVIEW, so could not see your vis.

 

Did you include your dlls in the 'always included' when building the executable? are the dll paths correct used?

 

If you can post your vis in a lower version, i can look into them.

Regards
Freelance_LV
TestAutomation Consultant
0 Kudos
Message 5 of 10
(3,218 Views)

is 2010 version fine?

0 Kudos
Message 6 of 10
(3,212 Views)

The thing is that the VIs are not important, it is only an example, my program is much more complex, but the thing is that when I run the executable of the VI the call function library node gives and error when it calls dll recursively ( the executable calls a dll and this dll calls another dll). It only happens when I create and run the executable. It works perfectly when I run the vi instead the executable.

0 Kudos
Message 7 of 10
(3,209 Views)

I have found the solution. I have just added the both dlls in the same folder as de executable is and it is working fine.

 

Thank you very much anyway!

0 Kudos
Message 8 of 10
(3,208 Views)

A little nitpick: What you describe is not recursive DLL calling, but simply a DLL depending on another DLL.

 

And the problem you see stems from the fact that when you call a DLL with the Call Library Node it can reside anywhere on disk as long as it stays at the same place relatively to the VI, as when the VI was saved. That is because the Call Library Node remembers the (relative) path of the DLL, when you browsed  to it in the Call Library Node configuration.

 

The same is not true for a DLL depending on another DLL. This only looks for the DLL name, without any path, and here the normal Windows DLL search order applies. When Windows tries to locate a DLL it looks in these locations in that order:

 

1) already loaded in memory

2) in the application (exe) directory

3) in the <system> directory

4) in the <windows> directory

5) in any directory listed in the PATH environment variable

 

So option 2) is what helped in your case

Rolf Kalbermatter
My Blog
Message 9 of 10
(3,191 Views)

Very helpful answer. Thank you very much 🙂

0 Kudos
Message 10 of 10
(3,186 Views)