Arrow when wire goes under object

[LarryWare]

Indicate when a wire is passing under an item, as opposed to when it is wired to the item. I had an error wire passing under the error conections for a object. I thought it was connected but it was not. I saw someone posted an idea for arrows, a bit too big. In a reply some else posted a note that there is a small gap shown in the wire. I could not see the gap, nor do I think it exists in LV2015SP1. I would suggest a clear gap or a thicker border at the point of connection to indicate the connection.

[RavensFan]

Wires should never pass under an item.  So the idea really should be how to indicate when a wire does so that the programmer can fix it.

Maybe something like you suggest would be good to give an immediate onscreen indication that has happened.  But there is already a way to find those situations by using VI Analyzer.

[LarryWare]

I did not name this Arrow when wires goes under object. Someone moderating has changed my intent. Another way to indicate this would be to make the wires the top layer, that is drawn over the top of the objects. I looked for an option to do this. I never intended to have the wire go under the object. Although I am new to LV, passing wires under an object seems like a poor choice. I normally code in C++, but using FPGAs for something. I will try running the VI analyzer. But still think there should be a way to see this.

[thols]

I would also prefer som direct visaul feedback instead of having to run VI analyzer. Through the years I had some nasty bugs which was caused by me duplicating a sub-VI and placing it on top of the same VI, when I was ctrl+dbl-clicking to show the diagram of that VI. The duplicate VI somehow got placed exactly over the sub-VI. This never happens anymore partly since almost all VIs I use have some connector that is set to required, but I still think that either there should be a visual feedback or there should be a preference setting making it impossible to put an item or wire over another item or wire.

[AnthonyDeVries]

I would prefer some visual feedback as well.  It indeed typically happens to the error wire when you change the order in which VI's are executed.  It has caused me a few headaches in the past.  

The obvious way would be to do it the same way as when wires cross other wires.   To indicate they don't touch eachother, the bottom wire is visually 'cut', to show that the crossing wire is going over it.   (The white pixels that are placed over the bottom wire)

At the moment, that is not the case with other elements.  VI's do not place those white pixels over non-connected wires, and thus it visually looks like they are connected.  (Labview 2015 SP1)

When VI's place such white edge pixels over non-connected wires, you would have a visually consistent indication that they are not connected.   That would be very nice to have.

I tried with one white pixel at the edge, and it already makes a significant difference.  However, considering the imporantance off knowing if they are conncted, and that there is no secondary visual indication, as with the dot in the wires, for showing connectivity, I would advise a 2 pixel edge. 

[AristosQueue (NI)]

RavensFan wrote:

"Wires should never pass under an item."

Personally, I agree with you, but there are many users, many of them high-level CLAs and/or major toolkit developers with strong G pedigrees, who disagree. The most common case I see is a while loop around a case structure. A value is computed at the start of the loop, passes into the structure so it can be used for one frame. That same value is then needed again after the case structure, still inside the loop. Rather than wire across all the frames or wire around the case structure, they will run the wire behind the case structure.

Because of this strong preference among a wide swath of the community, I don't think we can do anything to remove the ability for wires to run behind. Making that more obvious is possible.

[Darren]

Any idea that has not received any kudos within a year after posting will be automatically declined.