Extracting Function Pointer from VI Callback

[RickAlta]

I have a hardware interrupt function in a .NET DLL-C wrapper that registers a callback function for an Interrupt Handler (could be any callback function pointer).

How can I pass the equivalent of a VI function pointer to the DLL as an arguement? In a simple world, I hope to typecast the VI reference (function pointer) to an UINT32, pass to the .NET DLL as a regular UINT32 arguement, and then re-typecast on the DLL side.

Can I get the equivalent of 32-bit function pointer of the VI to pass as an arguement? Do you know another method?

I saw this solution:

http://msmvps.com/blogs/vandooren/archive/...rs-via-net.aspx

But sure seems messy.

Thanks,

Rick

PS...Good Site...

[Rolf Kalbermatter]

QUOTE (RickAlta @ Mar 19 2009, 07:59 PM)

I have a hardware interrupt function in a .NET DLL-C wrapper that registers a callback function for an Interrupt Handler (could be any callback function pointer).

How can I pass the equivalent of a VI function pointer to the DLL as an arguement? In a simple world, I hope to typecast the VI reference (function pointer) to an UINT32, pass to the .NET DLL as a regular UINT32 arguement, and then re-typecast on the DLL side.

Can I get the equivalent of 32-bit function pointer of the VI to pass as an arguement? Do you know another method?

I saw this solution:

http://msmvps.com/blogs/vandooren/archive/...rs-via-net.aspx

It sure is messy and with a lot of troubles. The alternative is to create a LabVIEW DLL from that VI and export it as a C function (watch out for the function prototype to be exactly like what the callback needs to be). However that has also its own problems. Unless the LabVIEW version calling (indirectly through .Net) this DLL function is exactly the same than the LabVIEw version used to create that DLL, the VI will execute in the LabVIEW runtime version that was used to create it and hence be a seperate process. This means there is no possibility to share LabVIEW data between your caller and the DLL directly since memory pointers, refnums and just about anything else have no meaning in the other. The same would apply if your .Net component would execute out of process since it would invoke the C callback pointer in its own process that would instantiate the according LabVIEW runtime.

The real question is why do you have this C .Net wrapper? If you would go directly to the .Net component and it would use .Net events for this asynchonrous notification the problem would be solved if you use LabVIEW version 8.0 or higher. There you can let LabVIEW handle .Net events directly by assigining it a callback VI that will be executed on occurrence of the event.

This whole .Net C wrapper makes everything unnecessarily complicated for you.

Rolf Kalbermatter

PS: If you can go with something more recent than LabVIEW 8.0 because of two reasons:

1) LabVIEW 8.0 had quite a bit of quirks in many areas. I have found LabVIEW 8.2.1 to be a lot more stable and reliable but 8.5(.1) or 8.6(.1) should work just as well.

2) .Net events were new in 8.0. So I would expect them to have one or two quirks that you might run into in that version that might have gotten fixed later.