Creating a DLL for use elsewhere

[eaolson]

For the first time, I need to create a DLL from a LabVIEW application that can be used by external code, probably C++. There is a great deal of information on calling a DLL inside LabVIEW, but not very much that I can find about calling a LabVIEW-created DLL from an external application. Can anyone point me to any reference? NI used to have a document Using External Code in LabVIEW, but I can't find a "Using LabVIEW in External Code" sort of document.

Some things are minor, for example the error cluster is defined in the created .h file as:
typedef struct {
       LVBoolean status;
       long code;
       LStrHandle source;
       } TD1;

That's reasonably straight-forward, but the TD1 name isn't very descriptive (I'm guessing that stands for Type Definition 1). Other clusters get TD2, etc. Is there any way to change these names to something more helpful? I worry that, if my DLL changes, these will all be renumbered, and that will make maintainability a nightmare.

Other things are considerably more confusing. I have a function that returns a timestamp in LabVIEW. In the .h file, this function gets a prototype that looks like:
void __stdcall GetTime(TD1 *errorInNoError, HWAVEFORM targetSTime, LVBoolean *timedOut, TD1 *errorOut);

The only definition I can find for HWAVEFORM is in extcode.h that LabVIEW drops in the DLL folder:
typedef IWaveform* HWAVEFORM;

And the only reference to IWaveform I can find is also in extcode.h, where it is defined as:
typedef struct IWaveform IWaveform;

I can't find any other definition or even reference to IWaveform.

(Crossposted from LAVA.)

[GregR]

You can safely rename the TDn names in the generated header to names that make sense for your interface. LabVIEW will give the same set of names every time given the same set of connector panes. However, if you modify the connector of one VI or even change the order of the exported VIs, this can change the numbers generated.

Accessing LabVIEW data types from external code can be tricky. If you are creating a DLL for general usage, I think it is best to eliminate as much of these types from your interface as possible. My goal would be to present a DLL interface that only uses types that are "normal" for C. This means passing strings as C strings instead of handles and passing arrays as pointers to the data instead of handles. For many data types the DLL build process can do for you. For complex data types like clusters with nested strings/arrays or waveforms, this can require some work in the VI before exporting.

For your case I would suggest modifying your VI or building a wrapper around it for export that simplifies the types involved. Split the error cluster out into separate parts so that the string can be passed as a C string. For timestamps your external code will probably want an integer second offset from some start time. Do that conversion in LabVIEW so the integer is exported instead.

There are ways of accessing LabVIEW data from external code, but in most cases you are building a DLL to give to people who are less familiar with LabVIEW so build your interface to be the most usable to them.