LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Possible to make my own API for other developers that utilizes the callback vi architecture?

Obviously there are many different ways to make an API in LabVIEW. Is it possible to create an API (in LabVIEW) that the end customer (other LabVIEW devs) interact with in the same manner as ActiveX/.NET registering event callback vis? This paradigm would be familiar and well suited to the people who would be using the API. 

0 Kudos
Message 1 of 4
(1,065 Views)

Well the closest possible thing to that would probably be to add something to your API that takes in a reference to a reentrant VI, and then when "something" happens in your API, it opens and runs the VI calling it by reference, using an asynchronous "call and forget" method.  You'd have to predefine a connection pane that the VI reference would need to match exactly, just like the callback VIs in .NET have a fixed connection pane.

 

However, just because that's the closest possible thing, it doesn't mean it's the best thing to use.  It might be better to simply create an instance of a User Event, and just fire that whenever something happens.  It's less complicated overall, and has the advantage that it can do nothing at all if there are no event cases registered for it, and doesn't need to worry about the root loop being busy.

 

Maybe a bit more details on how your API would work and how people would interface with it would help.  Are you going to be giving this out as internal code only, or making it for users in other companies to consume, or distributing it as a packed library, or what?  How often might it need to fire events... once a minute, or a thousand times a second?

0 Kudos
Message 2 of 4
(1,015 Views)

If you create a User Event, you should be able to register a callback in the same manner as an ActiveX/.NET event.

 

It's not something I've seen done and there might be some good reasons to avoid it, but I just did a quick test and it does seem to work.

Message 3 of 4
(984 Views)

IIRC, this option makes a difference:

wiebeCARYA_0-1654253196859.png

I think it needs to be off, or the references in one context (the dll) won't be valid in the host.

Message 4 of 4
(964 Views)