Right-click: Adapt Output Indicator to its wire

[Enrico_Segre]

I'm very often in this situation:

At some point I realize that I have to change somehow my output indicator, say adding an array dimension, changing an element type, adding a cluster element, whatever.

Well, if I could just right click and choose "Adapt Indicator to wire"....

My current best general workaround is the following:

1. Go to the wire source (may be far away on the BD) and right-click "Create Indicator"
2. Select the newly created indicator and double click it to select it on the FP
3. Ctrl-X cuts the new FP indicator
4. Select the old indicator on the FP (or go back to BD, double click...)
5. Ctrl-V replaces the old with the new indicator but leaves it on connector
6. Go back to the BD and rewire to the proper source/ remove broken wires

If the indicator I wanted to modify was, additionally, Hidden, there are a couple of steps more of Show/Hide... And if instead I invested in cosmetics of the indicator, I have to redo that again from scratch...

[Intaris]

And there is already a precedence for this in LabVIEW.You can tie a typedef to a given bitfile and have LV autoupdate the typedef for you in the background if the interface for the bitfile should change. Here the request is for exactly the same functionality.

[GregSands]

I'm coming down on the side of this being useful.  I think the wording would need to change though - "Adapt" suggests that it would behave like "Adapt to Source" on a numeric indicator, whereas I would assume this is a trigger, not a setting to "always adapt".  So maybe "Update Indicator to Match Input".

I don't see a Typedef by itself as a suitable workaround, although it should be able to work with an "Update" command, and would almost certainly be preferable.  The problem is that to modify a Typedef, you need to open it, find and add a suitable control (can be cumbersome if it is, say, a strict reference to a particular control), and then possibly reorder the controls to match.  In the case described here, the type is already available, though in wire form, and it is easy to add an input to Bundle, and put the new control wherever it suits, then click "Update" and the indicator (or typedef) changes to match.

Perhaps it would be easier to implement if "Create Indicator" on a cluster created a typedef by default (or at least as an option).

[Intaris]

Why can't I kudos a post.  GregS has got it.

Automatic udapt is perhaps the wrong approach, but an "Update" would be really cool.  I don't know how many times I've wished for this when implementing a user-event-based API and having to add a reference to a registered event to a cluster (where the datatype is a typedef).  After doing it 4-5 times, it really really is not enjoyable.

What better place to actually define a typedef than in the code responsible for initialising it?

[Enrico_Segre]

yes I meant one time update, not automatic. Like Create Indicator.

It seems to me that "Update the typedef based on this changed indicator, which is already associated to it" is also a valuable, but separate idea.

[tst]

If that is what you want and it bothers you enough, you can probably write a QD shortcut for it (i.e. take the wire connected to the terminal, follow it to its source, create an indicator from that terminal, move it to a new control, save that control, replace the indicator with that control. If it's already linked to a typedef, then do this to the typedef instead of a new control).

[PaulG.]

I see no reason not to create a typedef from a cluster as soon as I create the cluster. And I never use bundle. This idea encourages both and will only increase a vi's level of obfuscation.

[gnilsson]

 Although the purists comments about type def are right, I see no reason for not implementing this.
So often done:  delete indicator + right click create indicator

Especially  when experimenting, this would improve productivity, without having to side step into create a type def.