Do I have to preallocate memory of parameters that dll calculates

[Skoda3]

I'm using Call Library Function node to call .dll functions.

For example one of the function that I use is defined as:

unsigned long OpenInterface(void  ** Handle, unsigned long CommunicationType, void * pHandleInterface, unsigned char *PartNumber, unsigned long *pSize, unsigned long maxSize);

When I call this function I have to define input parameter "Handle" for it to function properly, and the function returns me PartNumber, pSize and other parameters.

My Question is:

Do I have to define constants of all output parameters before function is called? If I don't, do I have to be worry about somekind of memory errors? For example function OpenInterface calculates for me "Handle" in both cases: 1. If I define parameter handle as 0 before function call or 2. If I don't. 

[rolfk]

For skalar elements (single booleans, integers, floats) you don't need to wire a constant to the left side of the Call Library Node for quite some time already. Very old LabVIEW versions did not allow to have the left terminal unwired at all but that has been gone long ago.

For arrays (and strings) however it's different. You still can leave it unwired but LabVIEW will then pass in an empty array or string. That can be legitimate if it is an input to the function and the function allows empty strings to be entered (or if you pass in the native LabVIEW datatype and the DLL was explicitly programmed to deal with these datatypes properly by using the LabVIEW memory management functions to allocate, resize and deallocate those handles), but if the DLL wants to write something into that string or array to return to LabVIEW and you pass it into the DLL as C data pointer, you ABSOLUTELY have to preallocate the array or string to a size that is at least as big as the biggest size the DLL can fill in.

In your example you most likely (deduced from the naming scheme of the parameters but you will have to verify through the function documentation) want to preallocate the PartNumber string to the length (to be safe incremented by 1) that you pass in the maxSize parameter. On return the pSize parameter will likely contain the actual length filled into the string, though if you pass the PartNumber as C string data pointer, LabVIEW will only copy the data from the string buffer into the LabVIEW string up to the terminating NULL character in the buffer, so unless the function is doing something strange you would not really need to resize the string after the call to the number of characters contained in pSize.

Please note that your Handles are really pointers (to void) so you want to configure the according parameter to be a pointer sized integer, in order to prepare for seamless transition between 32-bit and 64-bit versions of LabVIEW. The first Handle parameter is passed by reference, so you should configure it to pass the Pointer to Value, while the pHandleInterface is passed by value (so it is an input variable), so configure it to pass the Value itself.

If you end up passing any of the Handle around between VIs you should use a 64 bit integer on the LabVIEW frontpanel in order to make sure everything works right in 64-bit LabVIEW. When executed on 32-bit LabVIEW, LabVIEW will use the correct part of that 64-bit number to pass to the DLL, if you configured the parameter everywhere as pointer sized integer in the Call Library Node.