From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
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:
Your first proposed solution works (directly configuring the static VI ref):
Setting the Options in a property is going to be weird -- no one is going to realize that what comes out of the node must be a different VI reference that has to be closed. It must be a different ref because it is configured differently for different calls, and if that ref wire has ever been forked upstream, you have a problem. If they're the same reference, then you have the problem shown in this picture:
Your second version (setting flags on the CBR node itself) has a lot of problems -- I won't get into all the technical details here, but you wouldn't like the performance of that notation if you're making multiple calls to that CBR. The ref needs to know its setup ahead of time.
Here's another option that could work:
Direct wiring of the static VI ref to open a new ref.
I like that little indicator on the static VI ref! That's what I'd consider the best solution.
But I refuse to accept the race condition excuse, just because if you wanted to prevent the programmer from creating race conditions, you'd have to come up with some really good ideas
Same race, different reference:
And to use one VI ref to open another VI ref is still unnecessarily complicated, don't you think?
Any change to G that I can make that makes a race condition impossible or avoids introducing a new one is a valid excuse. There is no class of bugs that is more likely to escape testing, harder to debug, and more likely to destroy user confidence in an application. They are to be fought with every tool in our arsenal. There are languages that did away with references entirely in order to prevent those abuses, and if I thought I could impose that on G, I would, but reference-less languages are hard to grasp for many people, so I do what I can to minimize their danger.
>The idea you linked is for a static clone reference, which personally I didn't have need for yet but I can see how it could be useful.
I wasn't hinting at the duplicate (but great catch), because indeed the context is different.
I mentioned the link because it's a similar solution to a different problem. The root of both problems is that a SVR is useless if you want options. The same solution would work: give the SVR options.
I would much prefer AristosQueue's last option: Direct wiring of the static VI ref to open a new ref.
There are only two ways to tell somebody thanks: Kudos and Marked Solutions Unofficial Forum Rules and Guidelines "Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
So... what exactly is the difference between the SVR and the opened VR? I mean besides of that the VR can be opened with options.
I was wondering if it would be sloppy to not close the SVR. A google search found this:
LabVIEWcloses thisreferencewhen the top-levelVIis no longer in memory. However, if you use the OpenVI Referencefunction with theStatic VI Reference, you will want to ensure youclosethereferencethat is passed out of the OpenVI Referencefunction.
Which is from the actual search. The link to this information just results in an error:
>So... what exactly is the difference between the SVR and the opened VR? I mean besides of that the VR can be opened with options.
There's not really a difference. A SVR is a VR. The SVR is just a way to get a VR. OVR is another. OVR is explicit, so it needs a close. Closing the SVR seems redundant, I never close them. When using a SVR to call a OVR, the OVR reference needs to be closed.
>When you open a reference to an application, project, VI, or other reference source, LabVIEW allocates memory to store that reference.
Uhh. Sure. It's data, so it needs memory for sure...
Not sure about the rest (it lingers a bit), but it's OT for this idea. It's your thread, so I'm OK with it.