> Could it be possible that LabVIEW 7.0 is not prepending the length > correctly to the blank buffer string when using the Pascal String > Pointer? Is there any way to check what the Pascal String Pointer > value and contents are when it is executed in the Call Library Node > VI? > > Here's the configuration I'm using for the DLL: > > void hasp(unsigned long service, unsigned long seed, unsigned long > lptnum, unsigned long pass1, unsigned long pass2, unsigned long *Par1, > unsigned long *Par2, unsigned long *Par3, PStr Par4); >
You don't give much information about how this fails to work? LV grew up on the Mac, and uses pascal strings all over the place internally. Anything is possible, but I think that the pascal string probably gives a 256 byte buffer with the contents of the input string copied in and the size set accordingly. If you can set a breakpoint in the DLL, even in assembly, it shouldn't be too hard to spot it, especially if you pass in a unique input string. As for generating a blank string buffer, you can use this VI I suppose, but a constant or any other string will work as long as it is of the expected length. And this is the most common mistake made using the Call Library Node. LabVIEW has no idea how big the buffer is supposed to be, or even if it is an input/output, versus an input, versus an output. The C language leaves that up the the programmer of the DLL and the user of the DLL. It is expected that the caller of the DLL allocate the right buffer size, and LV cannot help here. If you don't pass in a big enough buffer, the DLL will overwrite the buffer and corrupt other memory or get an access fault, depending on the layout of memory. Also, check if any of your input parameters describe the buffer size -- telling the DLL how much data you want returned, or telling it the size of the buffer. If you are inadvertantly telling it you only want two bytes, that might explain what you are seeing. Sorry I can't be more helpful. If you have more problems, please provide more information about the failures you are seeing. Greg McKaskle
