Provide an option to call a sub VI dynamically

[CaseyM]

When you drop a VI on the block diagram it's becomes statically linked to the calling VI. If instead you wanted to call the same VI dynamically (without creating an edit-time dependency by using a Static VI Reference) you'd have to change the code to, instead, open the sub VI's ref by path, create a type specifier and then wire the reference to a Call by Reference node.

Why not instead just provide the option to call a given sub VI dynamically by right clicking on the sub VI itself? I'm picturing a right-click menu that has two options:

• Static Call (default)
• Dynamic Call

If "Dynamic Call" were selected, all the steps to convert the call to dynamic would be handled would be handled by the IDE/compiler without the developer having to actively modify the block diagram. The IDE has 90% the information to make this happen, right? And the missing information could be provided by an options dialog if necessary (e.g. synchronous vs asynchronous call, run as sub VI vs top-level).

There should probably be some sort of visual indicator on the BD that the sub VI is being called statically vs dynamically.

[wiebe@CARYA]

An XNode might do this exactly as proposed.

Making XNodes is hard though... And there will probably be a performance hit.

How would such a node know the connector pane to use? If the VI isn't loaded\linked there could be a mismatch at run time. Would it use a strict VI type specifier constant (like wired to the Open VI Reference)?

[AristosQueue (NI)]

Weibe: I think you missed the point of the request (as I did originally). Read the details of the thread.

[wiebe@CARYA]

@AQ

I don't think so?

You can make an XNode that allows you to select a VI, but doesn't load the VI until you run it.

There would be no development time dependency to the VI in the .vim. The .vim would contain this:

With of course controls and indicators wired from the dynamic call to the .vim's terminals.

[AristosQueue (NI)]

But you would need to reflect all of that information (path, conpane) up to the draw level of the caller of the XNode, so it is no different than just putting the code directly on the diagram. The XNode wrapper is only useful if you're maintaining enough of an edit connection to keep that code up-to-date with changes to the subVI -- which is what I was trying to do with my original answers to this request. And the XNode would probably need a way to wire in "options" flags for it to be useful in all cases. Just transforming a subVI call into this code seems better.

[wiebe@CARYA]

@AQ Just transforming a subVI call into this code seems better.

Easier for sure.

The XNode would allow this with a drag\drop or browse interface. A benefit so small, I haven't started working on the XNode...

If you'd do this frequently, it would be annoying to make and manage all the "wrappers". The XNode would be a better experience, AFAIC.

I'm not sure how OP envisions to maintain a correct connector pane without dependencies. I think the only way to do this is manually: select a VI and it's current CP that will be the CP used for the dynamic call. If it changed, the XNode gives an error. Just like the subVI wrapper solution.

Usually, the edit time dependency is desirable. Using such a node much will give most people headaches.

[AristosQueue (NI)]

> I'm not sure how OP envisions to maintain a correct

> connector pane without dependencies.

That's the point... I believe that OP does not envision doing that.

[550nm]

How would you suggest runtime errors, specifically related to the call by reference, be reported?  For instance, compiler ("vi is not executable") errors discovered at run time?  Since the VI is not statically linked, such errors aren't known at compile time...

[wiebe@CARYA]

If you set a Call By Reference to "Reload for each call", the caller VI doesn't check at compile time if the sub VI is runnable.

So, for the suggested node, it would act the same: throw an error at run time.

I'd usually want a compile time error if things are wrong. But if you can live without that, I don't see any problems with the suggested node. Point to a VI, don't load or insert it, but use it's connector pane. At run time, dynamically (try to) load the VI. If it fits, great, run it. If not, return an error... No development time dependencies. No compile time error checking.

[CaseyM]

In the vast majority of cases, I want to see errors at compile time a well, but for this case I'm more than happy with the trade-off of only run-time error handling for lack of dependency loading. Given that, it would probably more sense to use this predominantly with well-tested/legacy code rather than code in active development.