Jump to content

Callbacks with DLL, Labview and helper code


Recommended Posts

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?  

Link to comment
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?

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.