> This DLL is supplied by the hardware manufacturer and I cannot > re-build or breakpoint the DLL as I do not have the source. I've also > looked at the excellent "Call DLL.vi" example that ship with LV7.0 and > have tried to replicate the Call Lib Node configuration in the VIs > (WinCHAR.vi, ANSIunsignedchar.vi and LVCStr.vi). > > Why is it that Visual Basic, LabWindows/CVI and VC++ can all execute > this simple DLL call but LabVIEW seems to have a real problem? >
To initialize a buffer, you can use a string constant, a Format into String, etc. If you split the wire and look at the data in an indicator before the call, you can turn on \ codes and look at the size and contents of the string going into the DLL. I went to the devzone sight, and looked at the previous posts. Though there is a lot of information there, not much is about what the DLL expects the various inputs to be. The magic numbers you are printing are addresses on the stack. Typeing those into P4 is not a good idea since that address is either going to be outside the LV app resulting in an instant exception being thrown by the OS, or it will be in the LV process and will simply corrupt something. So, wire up a string with verified contents and set the type to pascal string. If the DLL tries to realloc or free the pointer, or if it accesses data outside the input string buffer, it will throw an exception. LV will catch the exception, and the outputs will not be filled in. If you are still unsuccessful, you can try out passing information into your own DLL with the same signature. This gives you the ability to look at exactly what LV is passing in. You can also give the info to tech support and see if they can reproduce your problem. As for why it is easy in one environment and not in another, I think that will be more obvious when the mistake being made is figured out. I assure you that many many DLLs are called by LV including many of the NI I/O drivers. That isn't to say that there might not be a bug, but people use this successfully all the time. Greg McKaskle
