LabVIEW how to configure the path parameters in the call DLL library

[夜神]

LabVIEW how to configure the path parameters in the call DLL library. It is not the path of the DLL file, but the input parameter of the path (file) contained in the DLL.

[rolfk]

How can we know what you talk about? You show no VI ( preferably the real VI back saved to two version or more behind current LabVIEW and not just a picture) and no header file.

Unless the DLL was specifically written for LabVIEW any path parameters will be as strings however, but that could be either an ASCII string or an Unicode string. But LabVIEW only supports ASCII strings in the Call Library Node.

So let us see the header file.

[夜神]

Very sorry sir.

I don't have the header file now,but I have the picture of the function body.

The follow "TestDll.dll" is my call DLL library, the follow picture shows the function "bin to jpg", I don't know how to configure the "FILE" parameters in the LabVIEW call library.

the function bin_to_jpg can convert a BIN file to a picture.If test ,need to put the BIN file in the root directory of Disk D. The follow "2.zip" file contains a bin file.

[rolfk · Accepted solution]

You can not (easily) pass a FILE* fileidentifier from LabVIEW to a DLL. That has all to do with the fact that a FILE*  identifier is in fact a C runtime data type and even if you manage to call fopen() in LabVIEW to acquire such a FILE* identifier and then pass it to the DLL, you would be simply lucky if you were calling the same C runtime library that your DLL function is linking to. If the C runtimes do not match however, the FILE* identifier passed in from LabVIEW is totally meaningless for your DLL function.

This is NOT a LabVIEW deficiency! The same would happen if you try to call this DLL from a C program and you are using a different C compiler (version) than what was used for compiling the DLL.

So what should you do?

Reenable the fopen() call and pass instead the string containing the path from LabVIEW to the DLL.

__declspec(dllexport) int bin_to_jpg(const char *filename, int width, int height)
{
    FILE *fpr = fopen(filename, "rb");
    ...........
    fclose(fpr);
}   

Now you can convert the LabVIEW path into a string before passing it to the Call Library Node parameter configured as a String, C String pointer.

Also you called fclose() anyhow at the end of the function and that is a violation of resource managment rules. A resource (memory block, file handle, etc) should always be closed/freed by the entity that also opened/allocated it. Unless you have a clear managment contract that is enforced throughout your program, but that typically also requires custom data types that aid in resource managment with refcounting and other similar measures in place, and a very strict and methodocal application of these management rules. Anything else runs you rather sooner than later in a big mess.

Creating such a managed system and its rules is a tedious task so most programmers simply apply the rule to have the same entity always allocate and deallocate the resources.

And please remove the waitKey() call at the end too. A library function has no right to hold up execution like that!