A "This subVI" reference

[GeveauxE]

Using property nodes, it's possible to retrieve a list of subVI references within a VI's block diagram. However, there's currently no way to link each reference to its specific subVI instance.

For example, if you place three instances of subVI "A" in a diagram, you can obtain three references to these subVIs, but there is no way to determine which reference corresponds to which instance.

The proposed idea is to introduce a "This SubVI" reference — a property or node that would return the reference of the current subVI instance (the one hosting the object or node). This enhancement would significantly improve scripting capabilities, support tool development, and aid in debugging tools.

[wiebe@CARYA]

Would the reference return a VI server reference or a SubVI node reference?

The first is useful for VI server, the 2nd for scripting...

But for scripting, how would that work? The "This SubVI" reference would be on the diagram, so the reference would be invalidated if the VI stops.  But if it's running, you wouldn't be able to do any scripting.

A graphical mockup would help visualizing this.

[GeveauxE]

The subVI node reference (of type Generic > GObject > Node > SubVI > ...) is still a valid object reference, like any other GObject.
So I’m not entirely sure what you mean by "the reference would be invalidated if the VI stops."

So (correct me if I'm wrong, I've made some tests on subvi references to verify it) this reference remains valid. While it cannot be used to perform scripting on the referenced subVI during execution, it can be passed (via a queue, action engine, functional global variable, global variable, etc.) to another VI. That VI can then perform scripting on the subVI node — provided the owning VI is in an editable state.

As for the graphical representation, I imagine something similar to the existing "This VI" reference node, but labeled "This SubVI", pointing specifically to the subVI node instance it resides in.

Hope this is clearer.

[wiebe@CARYA]

>So (correct me if I'm wrong, I've made some tests on subvi references to verify it) this reference remains valid. 

In general allocated references are invalided when the top level VI stops running, but static references "outlive" this.  "This VI" references indeed seem to be static. 

This does mean you need to run the VI to get valid references so you can use it to do scripting, right? That doesn't seem very convenient to me. When scripting I typically do not want to run the DUT VI.

[GeveauxE]

Yes, you need to run the caller for the callee to know what is its reference.
There are methods you call when the caller is running, for example "ObjHighlight" or properties like "Breakpoint Status" : then you can do dynamic debugging at run time (for example).

Another use that can be done is what I do in the Grafcet Designer Toolkit (it's SFC, a sort of state transition graph) and at run time I use the property "Breakpoint status" to show which are the active Steps in the graph. So here you need to know the reference of a given SubVI to show it when corresponding step is active (not sure to be clear...).

[raphschru]

This idea would be great for scripting / debugging purpose indeed.

In practice, I don't think VIs have a link to the associated SubVI node from the caller's diagram, simply because the caller's diagram may not even be loaded in memory (or exist at all for PPLs where diagrams are removed)... There are also cases where a VI is not called via a SubVI node (top-level VIs, dynamically called VIs, ...).

The simplest "solution" I could think of would be something like that:

SubVI:

Then, in the caller VI, each SubVI instance must be given a unique ID:

A cleaner (but harder) solution could be to implement an XNode that would act as a SubVI node, but would also auto-assign a unique ID internally when dropped into a block diagram.

Regards,

Raphaël.

[GeveauxE]

Raphaël,

Regarding cases where there are no callers or similar issues, it's not a problem — the node just need to return an invalid subVI reference (like the GObject subVI constant node is).

As for your implementation, it's more or less what I'm currently doing (I'm using a private property node (the brown ondes...) to access objects other than constants). Honestly, it's cumbersome, doesn't work in all situations (Re-Entrant VIs cause issues), and it forces you to add unnecessary "decorations" (identifier). It's actually doing the job for what I need but my proposal would really give a true advantage (I think !).

As for XNodes, I've never coded one myself, but they have quite a bad reputation: undocumented, unsupported, non-portable, unstable, etc. Just like X Controls, Darren says to avoid them like the plague... and I believe him. But I'd still be curious and pleased to see your idea!

And finally, if you like this suggestion, consider giving it a kudo — it's the only way for the idea to get reviewed... since unknown contributors already start with a kind of built-in handicap when proposing ideas.

(Edit : I saw afterward that you did, thanks, I let the comment for others ! 😉 )

Thanks for the discussion!