You are here: NI Home > Support > Product Reference > Manuals > LabVIEW 8.5 Help

Complete the following checklist to eliminate many potential problems from LabVIEW VIs that call DLLs:

• The Call Library Function Node uses the proper calling convention (C or __stdcall).
• The version of your DLL matches the version of LabVIEW.
• Call Library Function Node has the correct path to the DLL.
• DLLs providing secondary DLLs additional functions are in the same directory as the DLL needing the additional functions or are in a directory that is in the search path.
• The Call Library Function Node has the correct spelling, syntax, and case sensitivity for the function name that you are calling. Otherwise, the error message appears.
• Data is wired to the input terminals of all the parameters of the Call Library Function Node that you are passing to a DLL function. Also, check that the Library Function Node is properly configured for all input parameters.
• Return types and data types of arguments for functions in the Call Library Function Node exactly match the data types your function uses. Erroneous data type assignments can cause crashes.
• The Call Library Function Node passes arguments to the function in the correct order.
• Resizing of arrays and concatenation of strings can take place only under the following conditions:
  • Only when the Call Library Function Node passes a LabVIEW array handle or LabVIEW string handle
  • Only when you add labviewv.lib to a Visual C++ project, and liblvexports.a to an Xcode project
  Never resize arrays or concatenate strings using the arguments passed directly to a function. Remember, the parameters you pass are LabVIEW data. Changing array or string sizes might result in a crash by overwriting other data stored in LabVIEW memory.
• The Call Library Function Node passes strings of the correct type to a function: C string pointers, Pascal string pointers, or the LabVIEW string handles. Windows API calls require the C-style string pointer.
• If you want to call a shared library that contains ActiveX objects, use the Automation Open VI with the Property Node and the Invoke Node instead of the Call Library Function Node.
• All parameters are defined to be passed by the correct method, such as value or pointer.
• Pascal strings do not exceed 255 characters in length.
• Remember that C strings are NULL terminated. If your DLL function returns numeric data in a binary string format, for example, through GPIB or the serial port, it might return NULL values as part of the data string.
• For arrays or strings of data, always pass a buffer or array that is large enough to hold any results that the function places in the buffer. However, if you are passing them as LabVIEW handles, use CIN functions to resize them under Visual C++ or Xcode compilers.
• When you are using __stdcall, list DLL functions in the EXPORTS section of the module definition file.
• DLL functions that other applications call appear in the module definition file EXPORTS section, or you include the _declspec (dllexport) keyword in the function declaration.
• When you use a C++ compiler, export functions with the extern "C"{} statement in your header file in order to prevent name mangling.
• For a DLL that you have written, never recompile the DLL while the DLL is loaded into memory by another application, for example, by your VI. Before recompiling a DLL, make sure that all applications making use of the DLL are unloaded from memory. This ensures that the DLL itself is not loaded into memory during a recompile. The DLL might fail to rebuild correctly if you forget this point and your compiler does not warn you.
• Test the DLL with another program to ensure that the function and the DLL behave correctly. Testing it with the debugger of your compiler or a simple C program in which you can call a function in a DLL can help you identify whether possible difficulties are inherent to the DLL or are related to LabVIEW.