complex .dll callbacks with library node

[TheSeeker]

Hello,

I'm looking for help on interfacing to an API implemented through a (complicated) .dll.

I've dealt with .dlls once before and had no issues other than teething pain.

The problem arose with the complexity of the callbacks.

I need to give the .dll a callback (pointer to a function) that has to have 3 pass parameters - not just one.

I upgraded to LabView 8.2 and thought it would allow configuration of the callback function prototype, but

I can not seem to figure out how/where this is configured (if it can be at all).

Am I out of luck?

I could write a wrapper .dll, but it would be a major time consuming pain in the ahrse for me right now and I'm trying to avoid going down that road (alas, I'm not getting a good feeling on this one).

Here is the prototype for the problematic .dll entry I'm calling - progressProc is the callback pass parameter.

typedef BOOL  (WINAPI *pfn_Learn)(HHANDLE hHandle, int codeFormat, char *Code, PLEARNCALLBACKPROC progressProc, void *userData, BOOL *pAbort, unsigned int param1, void *reserved0, void *reserved1);

And here is the prototype for the callback

void (WINAPI *PLEARNCALLBACKPROC) (unsigned int progress, unsigned int sigQuality, unsigned long carrierFreq, void *userData);

Is there any way to pass this callback fxn using the 8.2 library node? I need to know asap if I'm going to have to create a wrapper of some kind 

Thanks in advance for any help offered.

The Seeker

[rolfk]

---

@TheSeeker wrote:

Hello,

I'm looking for help on interfacing to an API implemented through a (complicated) .dll.

I've dealt with .dlls once before and had no issues other than teething pain.

The problem arose with the complexity of the callbacks.

I need to give the .dll a callback (pointer to a function) that has to have 3 pass parameters - not just one.

I upgraded to LabView 8.2 and thought it would allow configuration of the callback function prototype, but

I can not seem to figure out how/where this is configured (if it can be at all).

Am I out of luck?

I could write a wrapper .dll, but it would be a major time consuming pain in the ahrse for me right now and I'm trying to avoid going down that road (alas, I'm not getting a good feeling on this one).

Here is the prototype for the problematic .dll entry I'm calling - progressProc is the callback pass parameter.

typedef BOOL  (WINAPI *pfn_Learn)(HHANDLE hHandle, int codeFormat, char *Code, PLEARNCALLBACKPROC progressProc, void *userData, BOOL *pAbort, unsigned int param1, void *reserved0, void *reserved1);

And here is the prototype for the callback

void (WINAPI *PLEARNCALLBACKPROC) (unsigned int progress, unsigned int sigQuality, unsigned long carrierFreq, void *userData);

Is there any way to pass this callback fxn using the 8.2 library node? I need to know asap if I'm going to have to create a wrapper of some kind 

Thanks in advance for any help offered.

---

The feature to configure callback functions in LabVIEW 8.2 for Call Library Nodes is IMO misnamed. It is not to configure arbitrary callback fucntions that you could pass to a DLL function as parameter but rather some Initialization and Deinitialization functions that are called before and after your DLL function is called. That is not a callback in its proper sense, hence my opinion that this is a misnamed feature.

Callback functions are theoretically possible to achieve in LabVIEW but a total pain to do. You would have to define a VI with correct input/output paramters, put that in a LabVIEW DLL and export that VI from there with the correct function prototype. Then using LoadLibrary you can optain a pointer to that DLL function and pass it as callback pointer to your external DLL. A bit of a roundabout and tricky to do but it is possible if you really need to.

Rolf Kalbermatter

Message Edited by rolfk on 07-03-2007 12:42 PM

[martin.kretschmar]

Hello,

I have written and debugged some amount of multithreaded dlls, but none together with LabVIEW.

One void *userData is enough to preserve a pointer to ones specific user data strcutures, so the API looks sufficient.

And usually one wants call backs that work and don't damage the stack etc. So one fixed callback scheme implementation is the "norm" for every extensible computer language.

Since real interrupt style call back handling is very hard to implement, Windows has a call back queue.

This queue is processed only at suitable execution states, e.g. during I/O waits or SleepEx(n ,TRUE).

Regards, Martin