Array of cluster in defined size for DLL call

[cordm]

I'd like to emphasize rolfs first point: If you call a function from that other library before your wrapper, it can stay where it is. Maybe there is a harmless function to get the version number or something.

[MaSta]

The secondary DLL isn't called directly, only by the primary DLL. I found a solution.

There are other obstacles. What I have is a few DLLs, one of them primary, two related header files and an example project for Visual Studio. The example works. Now I'm trying to bring that code into LV. The DLL has 23 functions of which some use a complex structure. For that I initially created this discussion/question thread. The DLL importer cannot pass the VI creation at that point, so I have to create them manually.

The header file is, in my opinion, too complex. I'm trying to flatten it, so it's easier for LV's DLL importer to process, but it's not easy to find definitions which aren't in header files. 

I also learned to trick the importer about such complex structures by replacing them with a dummy array of the same size as the structure. But even with an input array of 1451 bytes LV struggles to create a control from it. 

[rolfk]

Basically the Import Library Wizard sounded at some point like a very nice idea. But the reality is that despite its name it is not a magician. And that would be required to make from just a header file a correct LabVIEW VI to call a DLL.

So basically even if the Import Library Wizard can create a VI there is no guarantee that it is correct. Many things are NOT defined in a header file and need to be known by the programmer using those functions by reading the hopefully available library documentation.

Basically if you can't create the Call Library Configuration correctly yourself, you also can't verify the Import Library Wizard generated VI to be correct. And if you can do it yourself, the Import Library Wizard is not saving you much time anyways.