VI callback (non-activex)

[Michael Aivaliotis]

In another post, Jim Kring suggested using callback vi's in his own development.:

I have figured out one use for this: defining a callback VI that will be called by reference.

[Michael Aivaliotis]

Someone asked me how would I pass data back to the caller.

Well, it is really simple since you would use the user parameter. I've attached a modified version with data sent back to caller. This would be the easiest method, however you can wire anything into this even a queue reference if you please. then data can be tossed onto a queue.

Download File:post-15-1073111204.llb

[Jim Kring]

I did some digging and experimenting and realized you can create a callback for any event. Now that's cool! Check out the attached example. Now the next step is to figure out how to assign callback vi's dynamically.

[Jim Kring]

The "Register Event Callback" node is only found on the ActiveX palette, but it works for all event types including VI Server Events (Application, VI, Control) and User Events. Does this mean that it is a platform dependent feature? I really doubt it -- it seams to be LabVIEW native. NI, what's the deal?

[Jim Kring]

Now the next step is to figure out how to assign callback vi's dynamically.  :wink:

This shouldn't be too hard. However, I believe that the callback VI framework requires the reference must be strictly typed and the VI must be reentrant.

[Jim Kring]

The "Register Event Callback" node is only found on the ActiveX palette, but it works for all event types including VI Server Events (Application, VI, Control) and User Events.  Does this mean that it is a platform dependent feature?  I really doubt it -- it seams to be LabVIEW native.  NI, what's the deal?

According to NI's documentation for the Register Event Callback

LabVIEW Documentation: event source ref accepts an ActiveX automation reference. Click the down arrow next to this input and select the type of event you want to generate, such as Mouse Down or Double Click. References must be to local objects. You cannot wire a reference to a remote object.

Is this a bug or a hidden feature?

[Michael Aivaliotis]

Someone emailed me the following:

I had an interesting discussion over email with someone from NI about the callbacks in general, and the impression I got was that they implemented them to make ActiveX events cleaner, but they weren't really a big fan of them with regards to how they're nearly the opposite of data flow programming.  That would lead me to believe it's the somewhat typical reaction NI has to LabView features they don't really like, they'll add them in but not disclose them at all, hoping people simply don't notice.

Some more discussion at NIWeek is expected...

[JasonKing]

The "Register Event Callback" node is only found on the ActiveX palette, but it works for all event types including VI Server Events (Application, VI, Control) and User Events. Does this mean that it is a platform dependent feature? I really doubt it -- it seams to be LabVIEW native. NI, what's the deal?

So I had to come join the fray. I guess this could be called kind of a "hidden" feature. We did intend to make it possible to use this functionality with non-ActiveX events. The idea was that, if you are already using this method for handling ActiveX events, you probably don't want to have to use the Event structure to handle all other events - you'd want to be able to have a common architecture. We waffled on this a bit, and made the decision late in the game to make this functionality available. That explains the fact that documentation does not mention that it can be used for all events.

I'll pretend not to be offended that no one read it, but in the article I wrote for DevZone that talks about the new events features, it does mention that the callback interface is available for all events. But it was a minor point, so I won't hold it against y'all

Nope, not platform-dependent. Yup, meant for it to be there. However, most users should stick to the Event Structure. It is much more straight-forward, and generally easier to use.

J