02-10-2012 07:04 AM
I have been trying for the past couple of days to figure out how to do the following:
I have been successful in getting back a regular C String from the LabVIEW DLL, I have been successful in getting back a Cluster containing a regular integer, but once I change it into a String and use the LStrHandle type, I get a weird memory dump file with no stack trace or any indication of what went wrong.
It almost feels as if LabVIEW specifically disables this functionality, i.e. does not want me to call into a DLL which uses a Cluster with a parameter of type Cluster with String.
I tried allocating the LStrHandle type by using labview.lib, but once I try calling the LabVIEW generated DLL, I get an error message stating that "LabVIEW.lib called from a non LabVIEW process".
I then get a memory dump file named "01e72e4a-d727-4245-bf2a-a2fc63975837.zip"
Anybody have success calling a LabVIEW DLL in such as way?
02-10-2012 08:42 AM
It's been a very long time, but I seem to remember problems transfering strings in and out of LV in this way. As I recall LV passes a handle to what used to a counted string where the first byte is the number of bytes in the string. Does your code work if the parameter being passed is an array of U8s? If so that could be an easy solution. Just pass an array where you have appended one element containing 0 to the end of the array. In the C world that would look an awful lot like a null-terminated string.
Mike...
02-10-2012 12:59 PM
I doubt anyone will be able to do anything useful with the dump file; could you instead attach your VI and the C++ function that calls it?
One thing I would try is writing a small LabVIEW program that calls the DLL (yes, you'll have a LabVIEW VI calling a DLL built from a VI). Make sure that works, then right-click the call library function node and choose "Create .c file..." This will give you a C stub demonstrating how to call the VI inside the DLL with the appropriate data types.