Chapter 1 CIN Overview

Incorrect example:

foo(Path path) {

PStr p;	/* an	uninitialized pointer */
File *fd;	/* an	uninitialized pointer */
MgErr err;

err = FNamePtr(path, p);

err = FMOpen(fd, path, openReadOnly, denyWriteOnly);

}

In the correct example, buf contains space for the maximum-sized Pascal string (whose address is passed to FNamePtr), and fd is a local variable (allocated space) for a file descriptor.

In the incorrect example, p is a pointer to a Pascal string, but the pointer is not initialized to point to any allocated buffer. FNamePtr expects its caller to pass a pointer to an allocated space, and writes the name of the file referred to by path into that space. Even if the pointer does not point to a valid place, FNamePtr will write its results there, with unpredictable consequences. Similarly, FMOpen will write its results to the space to which fd points, which is not a valid place because fd is uninitialized.

Debugging External Code

LabVIEW has a debugging window that you can use with external code to display information at execution time. You can open the window, display arbitrary print statements, and close the window from any CIN or external subroutine.

Use the DbgPrintf function to create this debugging window. The format for DbgPrintf is similar to the format of the SPrintf function, which is described in the Online Reference. DbgPrintf takes a variable number of arguments, where the first argument is a C format string.

© National Instruments Corporation

1-39

LabVIEW Code Interface Reference Manual

Chapter 1 CIN Overview

DbgPrintf

syntax

int32

DbgPrintf(CStr cfmt, ..);

The first time you call DbgPrintf, LabVIEW opens a window to display the text you pass the function. Subsequent calls to DbgPrintf append new data as new lines in the window (you do not need to pass in the new line character to the function). If you call DbgPrintf with NULL instead of a format string, LabVIEW closes the debugging window. You cannot position or change the size of the window.

The following examples show how to use DbgPrintf.

DbgPrintf("");	/* print an empty line,
	opening the window if
	necessary */

DbgPrintf("%H", var1); /* print the contents of an LStrHandle (LabVIEW string), opening the window if necessary */

DbgPrintf(NULL);	/* close the debugging window
	*/

Debugging CINs Under Windows 95 and Windows NT

The Windows 95 and Windows NT platforms support source level debugging of CINs. To enable debugging, add the following line to the

.lvm file of your CIN:

DEBUG = 1

cinLibraries = Kernel32.lib

These lines will add debug information to the CIN. You must also add the DebugBreak system call at the point where you want to break into the CIN code. After adding this information, recompile the CIN and reload it into LabVIEW. When you run the VI containing the CIN, a dialog box will appear with the following message:

A Breakpoint has been reached. Click OK to terminate application. Click CANCEL to debug the application.

Click CANCEL. This launches the debugger, which attaches to

LabVIEW, searches for the DLLs, and then asks for the source file of

LabVIEW Code Interface Reference Manual

1-40

© National Instruments Corporation

Chapter 1 CIN Overview

your CIN. Point to your source file and the debugger will load the CIN source code. You can then proceed to debug your code.

Debugging CINs Under Sun or Solaris

It is not currently possible to use Sun’s debugger, dbx, to debug CINs. The best you can do is use standard C printf calls or the DbgPrintf function mentioned earlier.

Debugging CINs Under HP-UX

You can debug CINs built on the HP-UX platform using xdb, the HP source level debugger. To do so, compile the CIN with debugging turned on. You must also enable shared library debugging with the -s flag and direct xdb to the source files for your CIN. For example, if your CIN source code is in the tests/first directory, you could invoke xdb with the following command:

xdb -s -d tests/first labview

See the xdb manual for more information. Once the CIN is loaded, break into the debugger and set your breakpoints. You may need to qualify function names with the name of the shared library. Qualified names are in the form function_name@library_name. The name of the shared library will not be what it was when compiled. Instead, it will be a unique name generated by the C library function tmpnam. The name will always begin with the string LV. Use the debugger command mm to display the memory map of all currently loaded shared libraries. CIN shared libraries are ordered by load time on the name space, so CINs loaded later appear in the memory map before CINs loaded earlier. As an example, to break at CINRun for the library /usr/tmp/LVAAAa17732, set the breakpoint as follows:

>b CINRun@LVAAAa17732

If you reload a CIN that is already loaded, the debugger will not function properly. If you change a CIN, you must quit and restart the debugger to enable it to work as desired.

© National Instruments Corporation

1-41

LabVIEW Code Interface Reference Manual

Chapter 1 CIN Overview

LabVIEW Code Interface Reference Manual

1-42

© National Instruments Corporation