Debugging DLLs and Calls to DLLs

When you debug your LabVIEW calls to DLLs, you must be prepared to trace problems in the DLL you are calling and in your implementation of Call Library Function in LabVIEW.

Troubleshooting the Call Library Function

When your LabVIEW calls to DLLs generate errors, check for the following problems in your use of Call Library Function. Also refer to the

Troubleshooting your DLL section and the Troubleshooting Checklist section.

•Make sure that the path to the DLL file is correct.

•If LabVIEW gives you the error message function not found in library, double-check your spelling of the name of the function you wish to call. Remember that function names are case sensitive. Also, be sure that your compiler has not decorated the function, as discussed in the Preventing C++ Name Decoration section.

•If your VI crashes, make sure that you are passing exactly the parameters that the function in the DLL expects. For example, make sure that you are passing an int16 and not an int32 when the function expects int16. Also confirm that you are using the correct calling convention __stdcall or C.

Troubleshooting your DLL

When LabVIEW calls to DLLs generate errors, check for the following problems in your DLL. Also refer to the Troubleshooting the Call Library Function section and the Troubleshooting Checklist section.

•Remember that you need to declare the function with the _declspec (dllexport) keyword in the header file and the source code or define it in the exports section of the module definition file.

•When you use the _declspec (dllexport) keyword and you are also using the __stdcall calling convention, you must declare the DLL function name in the EXPORTS section of the module definition (.def) file. In the absence of a .def file, __stdcall might truncate function names in an unpredictable pattern, and so, the actual function name would be unavailable to applications that call the DLL.

•When a function has not been properly exported, you must recompile the DLL. Before recompiling, you must close all applications and VIs that may make use of the DLL. Otherwise, the recompile will fail

Chapter 2 Shared Libraries (DLLs)

because the DLL is still in memory. Most compilers warn you when the DLL is in use by an application.

•After you confirm the name of the function, and after you confirm proper export of the function, find out whether you have used the C or C++ compiler on the code. If you have use the C++ compiler, the names of the functions in the DLL are altered by a process called name mangling. The easiest way to correct name mangling is to enclose the declarations of the functions you wish to export in your header file with the extern "C" statement:

extern "C"

{

/* your function prototypes here */

}

•Try to debug your DLL by using the source level debugger provided with your compiler. Using the debugger of your compiler, you can set breakpoints, step through your code, watch the values of the variables, and so on. Debugging using conventional tools can be extremely beneficial. For more information about debugging, please refer to the appropriate manual for your compiler.

•Calling the DLL from another C program is also an excellent way to debug your DLL. By doing this, you have a means of testing your DLL independent of LabVIEW, thus helping you to identify any problems, sooner.

Troubleshooting Checklist

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

Call Library Function uses the proper calling convention (C or __stdcall).

Call Library Function has the correct path to the DLL.

Call Library Function has the correct spelling, syntax, and case sensitivity for the function name that you are calling. Otherwise, the

error message Function not found in library appears.

In the Call Library Function icon, data is wired to the input terminals of all the parameters that you are passing to a DLL function. Also, check that the function is properly configured for all input parameters.

© National Instruments Corporation

2-27

Using External Code in LabVIEW

Chapter 2 Shared Libraries (DLLs)

Return types and data types of arguments for functions in Call Library Function exactly match the data types your function uses. Erroneous data type assignments can cause crashes.

Call Library Function 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 Call Library Function passes a LabVIEW Array Handle or LabVIEW String Handle, and,

–Only when you add labview.lib to a Visual C++ project, labview.export.stub to a CodeWarrior project, and labview.sym.lib to a Symantec project.

Caution 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 may result in a crash by overwriting other data stored in LabVIEW memory.

Call Library Function passes strings of the correct type to a function: C string pointers, Pascal string pointers, or the LabVIEW string handles. The Windows API requires the C-style string 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 may return NULL values as part of the data string.

For arrays or strings of data, you 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++, CodeWarrior, or Symantec compilers.

When you are using __stdcall, you 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.

Using External Code in LabVIEW

2-28

www.ni.com