Asyncronous Call By Reference

[Jim_Kring]

Here is an idea that I have wanted to make happen for a while. It is the Asyncronous Call By Reference. Basically, it is just a Call By Reference, but split in half so that the call is not syncronous (blocking), and return data can be obtained from multiple locations.  Plus, there should be ways to check the status of the asynchronous call and kill it.  I've even implemented this, to some degree, here http://forums.openg.org/index.php?showtopic=88

Message Edited by Jim Kring on 06-10-2009 08:14 AM

[JackDunaway]

---

Aristos Queue wrote:
So I decided to ask: Would it be a useful feature just to have the Call By Ref able to spawn a new running instance with no way to programmatically get the outputs later?

---

Another way to handle this issue is to require a strictly typed callback VI whose inputs match the outputs of the fire-and-forget VI. I really, really like the API designed by the .NET callbacks - if I remember correctly, there's a context menu item on .NET event registration that will create a template of the strictly-typed VI for you.

In my previous post, I said I don't care about the outputs. Well, this is partially true... If I care about the output of the CBRVI, I'll feed a messaging ref into one of the inputs. When I say I don't care about the outputs, that refers to the currently inaccessible outputs on the Connector Pane.

[G-Money]

Available in NI LabVIEW 2011 Beta

[jcase]

An asynchronous Call By Reference feature has been added to LV 2011. The feature is not implemented as described here but it should solve this use case. Please, try it out.

[G-Money]

There is a new API in LabVIEW 2011 that adds this functionality. The API in LabVIEW 2011 was actually started internally and was not caused by this idea so I am declining it. While the feature wasn't started by this idea, it should solve the functionality this idea was looking for.

[G-Money]

There is a new API in LabVIEW 2011 that adds this functionality. The API in LabVIEW 2011 was actually started internally and was not caused by this idea so I am declining it. While the feature wasn't started by this idea, it should solve the functionality this idea was looking for.

[Jim_Kring]

@G-Money: I'm biased, but I disagree with marking it as Declined, for a variety of reasons:

- (I'm assuming) Posting it on the idea exchange added leverage to get the feature implemented.  I think it only hurts NI to not give some credit to idea exchange contributors.

- I mentioned this idea to a senior member of LabVIEW R&D at an NIWeek (probably 2003 or 2004) many, many years ago, long before the idea exchange.

- I posted the idea as a proof of concept implementation publicly back in spring of 2005, long before the idea exchange.

- It was highlighted as a community contributed feature in the NIWeek keynotes, and it's featured as a community contributed feature on the what's new in LabVIEW.  No take-backs ;))