Forgot to enable notification so I'm just getting back to this. I apologize for that.
QUOTE(rolfk @ Dec 8 2007, 05:45 AM)
Feeding datastream_t with an int32 is working fine. Throughout the library I've made prior calls (prototyped similarly as regards to datastream_t) to other functions and it has worked out all right. I'm confident in the ability to handle that portion of the code. In fact, this chunk executes just fine, passing through the already established DataStream_ID successfully.
QUOTE
The void pointer quite likely is the culprit here.
I'm starting to hear that from numerous sources.
QUOTE
void pointers are especially bad in that respect as they can be really anything you can think of. What it is can only be decided by knowing the exact context of that function, which you didn't give in any way.
I apologize for that, but this is a proprietary code (despite the individual function's simplicity) and I'm only able to superficially describe the code. I cannot actually post the exact code. In that vein, this function call is made to determine the number of parameters in the established datastream. It should be returning an integer.
QUOTE
These things can not be deducted from the function prototype you show but only from the source code, a possible code example or the function description in some programmer manual to the library.
Big company + employees at two different locations with two different bosses = the developers binning my troubles with their code as not a priority. As such, I'm not getting too much support from the originators of this code. They have their own worries to consider. Lucky me.
QUOTE
Another possibility is that the function allocates the buffer itself and returns a pointer to it in the void parameter. In that case you would need the exact structure of that buffer and hope it is a flat buffer. Retrieving non flat data (pointers inside that buffer) in such a way is a mature pain and for me ALWAYS a reason to write a wrapper DLL or in your case since you have the DLL source code an additional more LabVIEW friendly exported function. Also since the DLL allocated the buffer it should provide you with a function to deallocate it later on after you don't need it anymore as otherwise you are creating memory leaks.
This has my head spinning. I don't know that I've really added much more context to the problem description, but I'll run your thoughts by the C code developers and see what their thoughts are on the concerns you've raised. Of course, that'll happen whenever I can pin them down to discuss this.
QUOTE
All in all there is way to little information available to tell you what exactly goes wrong and even less to give you detailed ideas about how to do it correctly.
That's what I was afraid of. That my limited ability to show you what the function(s) does would prevent me from actually being able to narrow in on a solution.
Still, I greatly appreciate you taking the time to consider this. If any other ideas pop up in yours (or anyone else's minds), I'd love to hear them. Thanks!
