Allow Asynchronous Call By Reference with Strict, Static VI Reference

[jcase]

The static VI Reference has the ability to be made strict. A strict and static VI reference shows the icon of the target VI (static part) and a small red star (strict part). This allows a strict, static VI reference to be wired directly into a CBR node.

However, the new async CBR feature does not work with strict, static VI references because it also requires option 0x80 or 0x100 to be wired into the Open VI Reference.

There should be a way to specify an async call inside a strict, static VI reference. That way, an async call can be made by way of a reference returned by a strict, static VI ref and not just with an Open VI Ref.

[AristosQueue (NI)]

Users need to specify "call and collect" or "call and forget" mode, so this idea would include new popup options on the static VI reference to set one of these two properties so that the ACBR node knows what to do when called.

[kegghead]

Also don't forget about the 0x40 option, the refnum needs to set to either allow serial or paralell calls if multiple ACBR nodes are made in succession.

[jcase]

Maybe the implementation should allow the user to set any open options flags on the strict VI reference. Some options might be useful in completely different use cases.

For example, non-strict static VI reference to reentrant VI with option 0x8 specified to allow a reentrant instance to be called by way of a Run VI method.

[francois-normandin]

Perhaps with a polymorphic selector?

[rolfk]

Conceptionally I do not like to intermix functionality. So the polymorphic selector or anything similar on the CBR or ACBR node feels like the wrong thing to me, as that function should not be concerned about the opening of a new reference and the possible options of that. Also it poses an extra problem for cases where it can't just use the passed in static refnum but instead needs to create a new one to open it with the right options. That refnum needs to be deallocated too! You could always deallocate it after a call, or only if the output refnum isn't wired, but that still makes the actual refnum handling a lot more complex and possibly performance costly.

If anything at all, such an option should be placed on the Static Refnum icon. This icon is already responsible for providing a working refnum so it could also include a method to define the options on that refnum. The CBR and ACBR should not be concerned about creating the right refnum at all.

[tst]

Another alternative would be to place this in a subVI's Call Setup dialog. Today, if you right click a subVI and select that, you get the option to control when it loads and unloads and then the subVI call is automatically wrapped in a CBR node. If we add it, it could use the same mechanism and it will allow us to make an async VI call.

Pros:

1. Cleaner code (only a single element on the diagram).
2. Maintains an existing idiom.

Cons:

1. Only handles the use case of a single static VI.
2. Hides the details of the call inside the dialog (unless NI adds some indications to the CBR node).

[AristosQueue (NI)]

Tst: I assume you're not interested in the Call&Wait case but only the Fire&Forget?

[tst]

> I assume you're not interested in the Call&Wait case but only the Fire&Forget?

Correct. In the case of the single static VI, the call and wait case is handled using a standard subVI call, so we don't need to add anything to get that option.

[tst]

P.S. I said my suggestion only covers the use case of a single VI (which is what's shown in the original image), but that's not actually true.

In the case of multiple VIs, the original suggestion would basically have a case structure around the static reference to select the VI. In my suggestion, the same case structure could be around the CBR node itself.

It's true that the first code is slightly simpler, because it avoids duplicating the config for the CBR node, but there's no real difference.