Editor hints for miswires?

[TurboPhil]

Here's a dumb mistake I think many of us can relate to:

It would be really nice if the VI were just broken in this situation. But I can understand why it's not necessarily simple to mark node *outputs* as required.

But maybe there could be a way for the editor to *hint* that there is a problem here. Maybe the bundle nodes could change color when the output terminal is wired, so you could get a little more obvious feedback if you screwed up like this.  The same could go for any other primitives that have a "for type" input (e.g. unflatten from string, variant to data, to more specific class, etc).

Granted, VI Analyzer could report bugs like this, but having a little more immediate feedback would probably be a big win.

(Let me know if this should be cross-posted to the NXG idea exchange, too).

[550nm]

I agree!

In general, when a wire passes underneath an unwired output terminal of the same type, then there should be some warning!

In the example below, the output of "WAIT FOR ALL CLEAR" has not been wired;

"Detonate" happens immediately after Initialize...

[JÞB]

VIA Already tests for wires under objects.  And, in the case of the example shown, the "Dead code" test will catch it too!  Its a test shipped with LabVIEW.  Could you be more clear about this idea?  

Or, more exactly, given a tool exists that implements your idea:  What benefit would you see by automating a single portion of the tool over training developers to use the tool provided?

[TurboPhil]

---

VIA Already tests for wires under objects.

True. However, VI Analyzer is a chore to run. And I think there would be value in more immediate feedback; it would probably save a lot of developer time.

I don't think it would be unreasonable to classify output terminals as "optional" vs "recommended"...or maybe add some additional category like "it doesn't really make sense to use this node without one or more of its outputs wired". And then hint to the developer that they might've left out a critical step. I suppose that could leverage the "dead code" test logic. I just think it would be worth completely automating.

[TurboPhil]

...basically, given the amount of time I spend waiting on spinning wheels while the compiler does.....something, it would be nice if it could also accomplish something useful.

[cowen71]

I agree, having something indicate suspect code directly would be nice.

As per your example, why bundle things to a cluster and then not use the output. Why add 2 numbers together and not use the result etc etc. This is not necessarily limited only to wires underneath output terminals.

[JW-JnJ]

I would agree with this in a sense. I think that "miswire" is a very ambiguous and hard to define thing. LabVIEW can't know your intent. I would narrow this suggestion down to "Make hidden wires a lot easier to recognize".

Have a very visible flag that shows when a wire travels under another wire or, more importantly, under a node without connecting to that node. Maybe something obnoxious that would trigger my block diagram OCD.

(oh, someone posted this exact comment image above... well kudos then)

[GregSands]

One (easy?) way to do this would be for each terminal to have a 6-px  space around it, so that any wire in that region is 50% transparent UNLESS the wire attaches to that terminal. e.g.

Is that obvious enough?

[cowen71]

I like the idea from GregS. Very simple. 🙂

[Intaris]

Gregs' idea is good but instead of the terminal having a 6px space around it, it's essentially the entire icon.....

[PalleM]

@GregS:

I do not think 50% transparency would be sufficient when dealing with boolean, see below image.

I think the big nasty red circle suggested by 550nm and JW-JnJ would be preferrable.

Also, I would prefer it was a global option whether or not these hints should be shown.

6pixel wide 50% transparency         red circle