mmitch Posted January 25, 2018 Report Share Posted January 25, 2018 Hi all. I'm going to ask this question without attachments to see if I get an quick obvious answer and if necessary, can upload my code examples. I've got a 3rd party DLL (no debug info, but know it is stable) that requires callback functions to respond to. I've gone the route of creating my own DLL to support the callbacks and relay the events to a Labview event structure. The way I have it set up is: 1) Labview calls an exported function in my DLL simply so that I can store Labview's UserEvent Reference parameter for the PostUserEvent function. It gets stored in a static variable. 2) A second exported function passes its callback function pointer up to Labview and Labview passes it to the 3rd party DLL. So I launch the system and things seem to work at first - my DLL actually gets called and relays data from the 3rd party DLL to a Labview Event structure. What seems to be happening: Getting a valid function pointer to 3rd party DLL, getting the event trigger in my DLL, properly calling the Labview user event structure using data allocated with Labviews native memory functions. BUT, then I get memory access crashes. So my question is, do you guys think this is because Labview is trashing (deallocating) my DLL callback function rendering the pointer invalid after a certain time?? And if so, is there a way to prevent this? And or, should I be taking a different approach and actually create a wrapper where the 3rd party DLL is called from within my DLL? Quote Link to comment
JKSH Posted January 26, 2018 Report Share Posted January 26, 2018 4 hours ago, mmitch said: I've got a 3rd party DLL (no debug info, but know it is stable) that requires callback functions to respond to. I've gone the route of creating my own DLL to support the callbacks and relay the events to a Labview event structure. The way I have it set up is: 1) Labview calls an exported function in my DLL simply so that I can store Labview's UserEvent Reference parameter for the PostUserEvent function. It gets stored in a static variable. 2) A second exported function passes its callback function pointer up to Labview and Labview passes it to the 3rd party DLL. (1) sounds fine. (2) could work, with caveats. You need to make sure that the data passed between LabVIEW and the 2 DLLs don't get destroyed too early. You also need to ensure that the 3rd party DLL is happy to be called from different threads, OR you make sure you only call it from the UI thread. 4 hours ago, mmitch said: So I launch the system and things seem to work at first - my DLL actually gets called and relays data from the 3rd party DLL to a Labview Event structure. What seems to be happening: Getting a valid function pointer to 3rd party DLL, getting the event trigger in my DLL, properly calling the Labview user event structure using data allocated with Labviews native memory functions. BUT, then I get memory access crashes. So my question is, do you guys think this is because Labview is trashing (deallocating) my DLL callback function rendering the pointer invalid after a certain time?? And if so, is there a way to prevent this? And or, should I be taking a different approach and actually create a wrapper where the 3rd party DLL is called from within my DLL? No, I don't think your callback function can be "deallocated", unless you tell LabVIEW to unload your DLL. It has a permanent address in your DLL, after all. What kind(s) of data is transferred between the DLLs and LabVIEW? How are you ensuring that things are thread-safe? Quote Link to comment
mmitch Posted January 26, 2018 Author Report Share Posted January 26, 2018 OK - thanks for the reply - issue found!! I accidentally mis-matched calling conventions. Once I swapped over to stdcall in my DLL (which matches up to 3rd party DLL calling convention) seems to be working now. :)) Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.