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...

[Manzolli]

How about using a "Type Definition" to automatically update all references to this kind of data?

[Enrico_Segre]

Then I would have to typedef the indicator before I have finalized what I'm going to wire to it, and for every perspective change, jump between both the typedef and the VI which uses it, and care to modify them consistently. Typedefs are certainly good for multiple references to the same object across hyerarchies, but here I'm only proposing an edit helper for an individual VI.

[RavensFan]

You don't need to have the typedef defined that early in your process.  But you should have had it defined before you got to this point.

Just edit the front panel indicator to turn it into a typedef.  Add the boolean.  You should use a a constant of that typedef wired into your bundle node anyway to define the elements of the cluster you are trying to bundle together.

Then go find everywhere that used your complicated, but untypedefed cluster and replace it with the typedef version.  Now you shouldn't have any problems again in the future.

[Enrico_Segre]

It is not what I mean. I know how to handle typedefs and when I benefit from them, and the cluster was just an example. I'd just like a mouse shortcut  as handy as "Create Indicator" for earlier in the editing process. That would do with a single mouse click instead of multiple windows swaps and/or choice from palettes.

[Intaris]

Oh the "You should have designed it like that" answer.... ugh.

Well sometimes we code to other peoples incomplete ideas of what they want. Making changes like this easier should be a no brainer.

[altenbach]

That idea seems to have the potential to create a huge mess. Where should it end? For example if multiple instaces of this subVI are scattered deep inside a hierachiy of existing VIs, should the change also propagate to all callers? If it doesn't, you break all callers. If it would, it is hard to avoid secondary problems. Suddenly, a typedef seems like a better idea. 😄

Another option would be to use objects instead. they can deal with mismatches.

[Enrico_Segre]

>Where should it end?

for my use case, on the FP of that VI. If I have already in mind that I need a typedef, I'm creating it from start. If I know it's going to need methods and inheritance, I start thinking at the class.

>If it doesn't, you break all callers

as much as you do, if you delete any subvi terminal in use. Then you go through and fix.

What shall I say? Doesn't make sense, don't kudo. Rather, what I realize could become notrivial, is the general algo for mapping the attributes of the mismatched parts.

[RavensFan]

---

@Intaris wrote:

Oh the "You should have designed it like that" answer.... ugh.

Well sometimes we code to other peoples incomplete ideas of what they want. Making changes like this easier should be a no brainer.

---

I hever said he should have designed it like he should have known all along what it was going to be.  I realize changes are inevitable.  But once you realize you need changes, then you go and make it a typedef so that the changes can be made easier then and in the future.

[RavensFan]

Oh the "You should have designed it like that" answer.... ugh.

Well sometimes we code to other peoples incomplete ideas of what they want. Making changes like this easier should be a no brainer.

[Intaris]

Making the changes to the typedef (as you propose) is exactly the tedious work he is trying to do away with. So given that I fail to see how a typedef helps.

[RavensFan]

It's no more tedious then making any other change.  What is tedious is trying to change it in multiple locations.