LabVIEW Idea Exchange

About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
Top Authors
Showing results for 
Search instead for 
Did you mean: 

Simplify access to vi reference options

Status: New

I find it always a hassle to create an asynchronous call with the need of the "Open VI Reference" block. A strict static VI reference should be sufficient. Options should be either available in the properties via context menu, via property node or as input of the "Start Asynchronous Call Node".


I didn't go through the effort to create a property menu example, but here is an a graphic showing the help example and what I would wish for:


Call Options Example.png

Proven Zealot

> I was wondering if it would be sloppy to not close the SVR.


Closing the SVR is a no-op. The Close Reference node will neither deallocate the SVR nor return an error. This allows the SVRs to be seamlessly included in arrays of other VRs so that the downstream handlers do not have to care how the references were opened. Similar behavior can be seen with the reference returned by the "This VI Reference" node.


> My expectation would be that it is the same for a SVR. Just that it's opened

> as soon as the VI, that contains the SVR, is loaded. Is that correct?


That is correct.

Proven Zealot

I do like some of these ideas since my use cases also following the common ones here. Paul_Cardinale posted an Asynchronous Call XNode over here that is pretty slick that does these pretty well.  Just standard XNode disclaimer, undocumented features, unsupported 3rd party XNode, etc.