A tool to find the source node of a wire

[altenbach]

Looking at messy diagram from forum posts (not mine!), I often find myself in a situation that I cannot really tell where an "interesting" wire is coming from. Triple-clicking just shows me a spiderweb of wire segments going in all directions.

Often, the leftmost wire end is near the data source, but not always. Maybe it would help if we could right-click on a wire and do a "find source" and a halo,(or donut or similar) would temporarily appear showing where the data in the wire is originating.

A wire can have many sinks, but only one source and the data source is the most interesting property of a wire.

A tool to find it quickly could be helpful.

This picture is way too ugly, but should give some idea.... 😉

[GregSands]

Sounds helpful.  It would be nice to have a shortcut too - "Home" would make sense.

[tst]

Try using this VI (2009). It could also be adapted to be a JKI RCF plugin.

This is what the core looks like, but the above VI will let you select a wire in any VI and push a button to get to its source. It will probably not go across tunnels:

[manu.NET]

Hello,

Perhaps a "highlight wire" would be more efficient ... because maybe it may exist more than one source.

Manu.net

[manu.NET]

Sorry,

There is only a source (I am not awake this morning) ... but highligthing the entire wire to "the source" and to "all other destinations" could be very helpfull.

And one more sorry for my "Multiple source"

[altenbach]

> because maybe it may exist more than one source.

As I said, a wire has exactly one source. If there is no source or more than one source, the wire is broken for obvious reason.

> Perhaps a "highlight wire" would be more efficient

We can already highlight the entire wire by triple-clicking it. This has nothing to do with the idea. Read it again.

[altenbach]

> Try using this VI (2009). It could also be adapted to be a JKI RCF plugin.

We seem to have a problem, because the tool can only be used once during a run. The second time it throws an error because the reference got lost in the unwired output tunnel., Still, yes, that seems to show that the idea could be implemented very cheaply. 🙂

I don't expect it to go across tunnels. Imagine it goes back to the output tunnel of a case structure: it would not be able to decide which case to enter.

[tst]

> We seem to have a problem, because the tool can only be used once during a run. The second time it throws an error because the reference got lost in the unwired output tunnel

Good point. The fix, obviously, is easy - wire the app reference through. I also just modified the template I use so the tunnel does not allow default values, so at least this won't happen again. A good idea would probably be for the event stucture not to have tunnels with default values by default, but I wouldn't be surprised if this has already been suggested, probably even by you.

[JackDunaway]

How is this tool useful for a developer who does not write spaghetti or Rubey code? The original example needs the BDCT, to fix the reverse dataflow in addition to the overlapping wires/nodes. (In other words, this tool is not sufficient to read the above code because of other style violations. And after BDCT is used, the value of this tool is diminished)

[stbe]

Hi tst,

I allowed myself to modify your snippet -> there's the nice possiblity to find out whether a terminal is the source or not. This snipped will highlight the actual source - it just needs a wrapper (quick-drop or right-click-framework plugin) to work while debugging 🙂 

greets.

[rgvdh@rdf]

Source would be nice, or possibly little arrow marks showing which way the data is flowing down the wire.

Yes, it's supposed to be right and down, but sometimes that isn't possible.