event handler called by external SDK. How to implement in LV?

[Enrico_Segre]

I'm interfacing Labview with a third party, proprietary SDK.

I ran into something which is a hard nut to crack for me, despite extensive experience with external libraries.

There is some kind of data which I can retrieve from this SDK only via event notifications - in the way the SDK wants, not in the one I'd like. That is, I'm supposed to pass to the SDK a handle, i.e. a pointer to a callback routine. Later on, anytime the SDK thinks it fit, it will call the routine pointed at by the handle I initally passed, passing to it the data I need. According to the SDK's own documentation, I'm supposed to register my event handler at the beginning, with a certain call

EdsSetObjectEventHandler( ..., EdsObjectEventHandler inObjectEventHandler,...)

where inObjectEventHandler is the handle to the callback function, which needs to comply with the prototype

(EDSCALLBACK *EdsObjectEventHandler)(...data...)

The SDK should call this function when the need arises. How can I implement something the like in Labview? I don't know how to call a LV "anything" by C-like pointer reference, nor I understand in what execution thread that needs to sit. I'm caring for making the returned data available to LV in any form whatsoever, not necessarily as a LV event. I.e., even if this data would be written asynchronously to a resource, say a global variable, which LV could poll, I wolud be happy.

Thanks in advance for any idea,

 Enrico

[rolfk]

You'll have to write an intermediate C code library that translates between the C callback and some LabVIEW means. Look for PostLVUserEvent() here and on lavag.org.

[Enrico_Segre]

Thanks Rolf,

In fact after posting I refined my set of search terms, and ran into some of your earlier posts, where you reiterated this answer to very similar questions. Too bad, I really hoped it was to conoct some all-LV solution, but as such, I'll go for a compiler and break my head on wrong pointers and wrong threads.

Thanks a lot for your time,

Enrico

[rolfk]

---

@enrico Segre wrote:

Thanks Rolf,

In fact after posting I refined my set of search terms, and ran into some of your earlier posts, where you reiterated this answer to very similar questions. Too bad, I really hoped it was to conoct some all-LV solution, but as such, I'll go for a compiler and break my head on wrong pointers and wrong threads.

Thanks a lot for your time,

Enrico

---

If your callback function DLL insists on being called with specific threads, then I wish you a lot of fun!! I would simply ditch the DLL in that case as this is almost undebuggable. At least I hope it spins it's own thread to invoke the callback itself then. Calling the callback in the context of an API call requesting that call to be made in a specific thread would be posing serious troubles in LabVIEW.

[Enrico_Segre]

You deserve completely my kudos, Rolf. I managed to do what I was after, essentially along the lines of the solution of vugie on this thread on lavag.org, to which you also actively contibuted.

There was one threading quirk, though. It turned out that I needed to implement a message pump, whatever that is, in order to get the callback work. I had to include another function my the wrapping DLL, which calls some 

GetMessage(), TranslateMessage() and DispatchMessage().

I had not the vague idea of what they are exactly for and their implications, I copied blindly a suggestion I've found on a relevant interest group, and it worked.

The complete story, for the record, is on this thread. And if I didn't mention it, the motivation was to wrap to labview the SDK provided by Canon for a family of their SLR cameras.

All the best,

Enrico

[rolfk]

Your message pump is a little strange since LabVIEW as a Windows application should implement that also. However it's possible that they do not use GetMessage() but PeekMessage() instead in order to do some fancy internal LabVIEW event handling.

This part is probably one of the most delicate places in the LabVIEW code base and I doubt there is more than one or two guys at NI who still understands why LabVIEW does work in that place the way it does, and they probably keep their fingers crossed with every new Windows version, hoping Windows hasn't changed something internally in that place.

Apartement threading is a specific term in OLE/ActiveX meaning that the actual component can work in a multithreaded application but needs itself to work in a single thread. The communication with the multithreaded app is automatically marshalled (translated) by the OLE framework but for this marshalling to work, the application has to have an active message loop (or as they call it message pump) since the marshalling hooks into that message handling to be guaranteed to be active even in non-preemptive Windows 3.1 and also for synchronisation with the application.

[Enrico_Segre]

In fact I have to correct myself: there is no need for an event pump!

I started to suspect, since my callbacks worked even if I just placed the call to the "pump" procedure, i.e. the three Message() functions, which run once, not in a loop, anywhere in the call chain. It turns out, I think, that what causes the callback to work is that the dll containing the callback is known by LV, in some way. By accident, or better for compactness, I happened to have written both my event handler and the "pump" routine within the same dll. Now I see that the callback mechanism  works if just I place on my block diagram the subvi wrapping the event handler in a Disabled Diagram structure anywhere.

That is simpler and hence preferrable. I thought that elements in a Disabled Diagram were not even loaded in memory, but maybe I remember wrong. If they are, I suppose that there may be something like LV having them run in a thread it likes, but I really don't understand what is under the hood.

Enrico