> To retrieve data, the library expects you to provide pointers to variables > for each column you want to retrieve from a table. You then call "Fetch" to > get the next row into those variables, and then read them and do whatever > with them before calling "Fetch" again to update them with the next row. > > This give a problem with Labview; I've tried passing an I32 by pointer to > the library and then running the value through a FOR loop and autobuilt an > array on the output to try and get it to update each time I call "Fetch" > inside the loop- no luck, as far as LV is concerned the variable hasn't > changed. > > I've also tried creating a control, passing a reference to it, getting the > "Value" property and passing *that* by pointer to the library, then reading > the control by reference in the FOR loop. Still no luck. >
This is one of those fantastic DLL interfaces that causes everyone heartburn, C programmers that get it wrong just crash and pull their hair out as they try to debug it, and it doesn't fit very neatly into any of the typical cases that the DLL Node handles. The DLL wants you to give it pointers to buffers. Then you call fetch and it messes with the buffers using the pointers you gave it, then you dereference the pointers to read the contents, then call fetch again... And of course when you are done, you might tell it to forget the pointers, or maybe you just stop asking for fetches and release the buffers. The reason this doesn't fit into LV very well is that it doesn't fit into dataflow very well. There is no call that returns data, it is instead stashed into pointers agreed to in advance. I'm pretty sure you can get this to work by making multiple numerics that you pass into shift registers on a loop, then inside the loop pass the numerics by pointer into the registration call. Then put a sequence wrapper around the Fetch DLL call and pass the numerics in and out of the sequence, but don't send any into the DLL node. I think that the output value on the wire coming out of the sequence will be the stuff written by the DLL. Of course I haven't written anything to test it, and this "wiring near the DLL code" could stop working in a future release or when you make some other change to your diagram. The safer but more difficult solution is to write a wrapper DLL call that either points to static buffers or allocates them. Be sure not to give it pointer to stack variables or you will cause some nasty corruptions. Greg McKaskle
