LabVIEW
Copy untyped void * buffer over LabView struct equivalent
The information itself should be able to be TypeCast to a cluster, but the pointers are usually a hazzle.
/Y
It depends if the structure contains pointers or not. Any pointer element such as variable sized data elements including strings and arrays, or function pointers will not be possible to be simply mapped to LabVIEW datatypes. If the structure only contains skalars or fixed sized arrays you can define in LabVIEW a cluster with compatible memory layout and pass that cluster directly to the according function parameter.
Since LabVIEW is an early binding language you obviously can't switch the cluster type on the fly but instead will to have to write one VI with the correct structure type for each possible pointer type of your function and call them in the correct places.
no need to recompile the DLL at all. It seems you think that the type you see in the Call Library Node has to match with what the DLL defines. That is not true at all. All the DLL interface really matters is that the caller (here LabVIEW) and the callee (your function) do agree on the actual data put into the pointer. If the DLL prototype calls this char *, void *, my_superstruct * or whatever doesn't matter.
What you tell LabVIEW to put in the cluster has to match with what the DLL wants to pull from the structure, that is all that matters. So you can write xig VIs all implementing various cluster types being passed to that function and all of them calling into the same DLL function. Of course your function will probably need a parameter that tells it what specific datatype the caller has used. It's a possibility that this is not part of the function call itself but depends on some other function called previously but that is rather unsafe to do, and I would not recommend to use that if possible to do otherwise.
@bitblti wrote:
All contents are scalars or fixed sized arrays. This is basically just a simple network messaging protocol. The user will define a specific message contents and mapping in the VI, request the current value for that specific message, and the DLL will return an untyped buffer containing that message. The problem is I can't recompile the DLL everytime a new message is defined or layout is changed. I wanted to be able to do that in the VI and leave the DLL generic. When reading a message, the DLL just gets passed an integer ID, and returns the address to the buffer and the size of the buffer. When writing a message, the DLL jgets passed the same thing.
We're already doing this in c++. I'm using LabView for development displays and controls, and to provide quick and simple simulation stubs until our simulation environment catches up with the target software. So the user needs to be able to define the message structure and write any code to pull it out of the untyped buffer, within the VI. I can easily cast in c++, in fact thats how the target code does this. How do I cast an address over a cluster in the VI?
Well you simply configure the parameter in the CLN to be a byte array, passed as array pointer. The CLN configuration defines what LabVIEW should make of the parameter, not how you created the C code to look like. So if you want to pass an array you have to configure an array and if you want to pass the data pointer (instead of the LabVIEW array handle) you configure that in such a way too). If the DLL wants to treat it as void*, char*, mystruct* or whatever is completely beyond the scope of the CLN configuration.
Of course it is handy if the CLN configuration and the way the C function treats the parameter are compatible with each other in order to avoid crashes, but the CLN configuration really is only to tell LabVIEW how it should pass that parameter and nothing else.
And if you invest a little more time on the LabVIEW side to create a cluster that has the same layout as your C structure, you can go even further. Configure the CLN parameter to "Adapt to type" and wire the cluster directly to the parameter and you are all set. This will pass the pointer to the memory the cluster is occupying.
Why so complicated? If you pass a pointer sized integer you only pass the pointer itself. That is nice for opaque pointers such as handles that you do not to look at in LabVIEW itself but simply pass to other API functions through the CLN.
But here you want to look at the data so it is much better to use a datatype that you can look at in LabVIEW. A byte array buffer is one possibility, which could be then viewed in an array indicator or converted to a string and viewed in a string indicator. But a cluster would be even more handy in the final solution, as explained in my previous post.
Just don't forget that for C API functions the caller is supposed to provide all the memory buffers the callee should fill data into. So in LabVIEW if you go with a byte array you need to allocate it beforehand with the Initialize node. If you use clusters directly, the cluster definition itself is already the memory buffer where the function can fill in its data.
