Allow Strictly Typed VI References to auto update Type Defs that are on the connector pane.

[MPCC]

The need for this rears it's head when using the 'Start Asynchronous Call' VI.

In this situation, the input terminal for the Async VI is a type def.

When a Type Def Control connected to an input terminal is modified, the connection to the start Asynchronous Call VI is broken. To fix this, you must manually browse to the VI and update the static input.

I propose that there be an option on the Strict VI reference that allows Type Defs on the connector pane to be automatically updated.

[tst]

Just make the static reference strict (with a right click). The only problem is that there are sometimes some bugs when doing this (such as crashes or hangs if doing this in the actor framework), but it does work in priniciple.

A better solution in general would be to change the run async node such that you can configure it to statically run a specific VI and then you don't need all this code.

[MaryH]

Already in LabVIEW - Right-click on the static VI reference and enable the "strict" option

[MPCC]

I don't believe that this fixes the problem. It only partially resolves my issue. Look at the following example:

I want to store my static VI ref in a shift register. (I plan on waiting on the VI in a different case.)

I CANNOT put the VI Ref that was changed into a strictly typed VI ref into the cluster, I can only create a static constant and place that in the cluster. This causes the same issue.. until I update the static constant in the cluster, I will have a broken wire.

Maybe I need to start a new, more specific idea that requests Strictly Typed VI refs be allowed in clusters?

[tst]

OK, so what you actually want is a data type which is a strict VI reference of a specific VI, without actually being a reference to the VI itself (since presumably you want to be able to use different VIs). I'm not sure whether that's reasonable or not (it's reasonable in the "why not?" sense, but something that links only to the connector pane of a VI without linking to the VI itself sounds a bit weird and I haven't really felt the need for it).

What I would suggest as a workaround would be creating a typedef for the reference. That way you would still have to update the reference manually, but at least you will only need to do it in one place and presumably the code will break to let you know that you need to make the change.

[MPCC]

I'm not sure that we are on the same page. I want the strict VI reference to the specific VI to update automatically when a type defined datatype connected to it's connector pane updates. (because of strict static VI references, we have this) I then want to be able to place that reference in a shift register.

The end result is that I want is to be able to use Asynchronous Call and Collect in different cases without having to browse to and link back to the VI every time I update the connector pane of that VI.

[tst]

I get what you're saying, but it doesn't apply just to typedefs on the connector pane. It applies to any change on the CP (changing the pattern, adding I/O, etc.). The only thing I was saying is that it looks a bit weird that you have something that's linked to only part of a VI. It's not wrong - I think your use case is a valid one, it's just weird.

[AristosQueue (NI)]

OH! I agreed with tst earlier and asked that this idea be closed as already existing. Now I see you're requesting something else... you want "use a particular VI's conpane as if it were a typedef for all the controls/indicators downstream" and probably some combination of with "require one VI to always match the conpane of another VI, where the second VI defines the API for a dynamic function call".  Yeah, I've wished for both of those on many occassions. I thought that this idea already existed on the Exchange, but I cannot find it.

I'll ask a moderator to re-open your idea now that I have a better grasp of the request. Yes, it is an annoyance that would be nice to have solved.

[Brad]

My use case is a little different, but it sounds like this is exactly what I want as well. I have several Open VI Refs where the connector pane is wired in. Some of the type defs used on the connector pane may change, so I really like having the Strict Type def linked to a VI so it's connector pane automatically updates when the VI updates, but I don't like the Static Refernce loading the VI into memory. One main reason is that the VI may actually live on a different system where I am trying to dynamically call it and I don't have the dependencies on my system so the loading of the VI would fail. It sounds like what this suggestion is for is a "Statis VI Reference" (like we currently have that can be tied to a specific VI's connector pane and automatically update when it changes), without actually trying to load the VI into memory wherever this Static Reference is used.

Hope to see something like this in the future.

Thanks,

Brad

[AristosQueue (NI)]

Brad:

a) You would still have to have the VI on your local system otherwise we wouldn't be able to get its connector pane.

b) No, this isn't quite the same as a static VI reference... this is a "Not A Refnum" control/constant/indicator whose type is tied to a particular other VI.

c) Not having to load the VI is an orthogonal request -- the way the dependency system in LV works today, any dependency of one VI on another requires the other VI to be in memory. To do some sort of partial loading for one dependency connection would require a more substantial change of LV's entire linking behavior. Not an unreasonable request, and, indeed, something we have been working toward for a while now, but unrelated to this request. This request could move forward whether or not we ever tackle partial loading for dependencies.