LabView access to third party .dll files?

[ChadAnd]

I am trying to create a GUI interface to multiple software systems running on a windows 7 machine.  The objective is to have one LabView user interface that can control three different non LabView software systems running in the background.  Two of the programs have .dll files.  My goal was to use .dll files to interact with features of the non LabView software.  I have tried to bring one of the .dll files into labview but it was not successful.  

What do I need to ask for from the other software vendors that would allow me to access the .dll files?  Does it require a header file?  Do they have to give me permission to access features of the .dll?

[ToeCutter]

You just need to use 'call library function node'. You will need to know the input parameter format (contained in the header) to use a function.

[nathand]

Can you be more specific than "it was not successful"? Did you use the DLL Import tool, or did you configure Call Library Function Node yourself? What error occurred? What didn't work?

Do you know if these DLLs are standard DLLs, or .NET assemblies? Both have the same .dll extension, but need to be treated differently. What does the documentation from the vendor tell you about these DLLs? Does the vendor support calling their software from another program? If so, they should provide information on the interface.

[ChadAnd]

All good questions and a very good place for me to start. I havent interfaced to dll's before using labview so im not sure the specific questions to ask the vendor.

[billko]

If you have the source code, you could do Tools --> Import --> Shared Library (.dll)... which will open up a wizard that will parse the source code for the function calls and set it up automatically, once you answer a few questions...

[Dennis_Knutson]

The source code is not required for the wizard. I believe it parses the .h file.

[billko]

---

@Dennis_Knutson wrote:
The source code is not required for the wizard. I believe it parses the .h file.

---

Technically, you're right.  It's just that usually the .h code file (it's late) is included when you ask the software vendor for the sdk.