advanced dll questions in Labview

[falkpl]

I am trying to encapsulate some win23 API functions is labview and am having trouble with calling dll functions which use complex data structures, specifically nested struct pointers. I have no trouble with functions using simple data types or structs of only simple data types but how do you accomplish the following function calls:


int FunctionA(complexStructure *cs);

where the comples structute is defined as

complexStructure{
structA *a;
structB *b;
}

The issue is like derefferencing pointer to pointers?
Are clusters of clusters are flattened to contigious data in labview?
Here I want to pass a reference which has subreferences, and preallocate the approperate memory so I can pass such references, but I am stumped on how such calls are made using the Labview function call node. It would be nice to be able to use any dll but I just cant get these calls to work. Has anyone else experienced similar situations?

-Paul

[Steven_H.]

When LabVIEW passes a cluster of clusters to a Call Library Function, the outer cluster doesn't contain a pointer to the inner cluster; it contains the inner cluster itself. (The inner cluster may contain pointers, depending on its own components.) You can see this by wiring such a datatype to the node, right-clicking and selecting "Create .c file", and inspecting the resulting code.

The two ways to determine how a specific datatype in LabVIEW will look when "translated" to C are:
1. Read the "Using External Code in LabVIEW" manual, which ships as a PDF with LabVIEW. This covers the basic datatypes.
2. For the more complicated types, experiement with "Create .c file" as explained above. Your goal is to make the generated prototype match that of your function.

Having said all that, I can't think of a LabVIEW datatype whose C equivalent matches the specific definition you give. LabVIEW tends to store handles (double pointers) instead of pointers to variable-size data like strings and arrays. But there may be a LabVIEW datatype I'm not considering that would work.

Unfortunately, if there's no equivalent LabVIEW datatype, the only workaround is to create a small wrapper DLL or CIN to manage the translation.

Steven H.

[falkpl]

Thanks I had a feeling that I was stuck on this problem. I will take your advice and create a wrapper to break down the dlls to labview friendly signatures and then call the new functions. I guess that's the problem with managed memory, saves us form the hell of pointers but can cause some restrictions on the flexibility of a language.

Paul