LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
X.

Do not duplicate a wire label when splitting the wire

Status: New

I do not like the default behavior of wire labels (which I do not abuse BTW).

 

Before:

 

ScreenHunter_001.jpg

 

After:

 

ScreenHunter_001.jpg

 

It is easy to solve (by the user): Tab to Text edit, triple-click the extra label and delete the content (or hide the label). But it is a show slower...

Thanks for CARifying this.

5 Comments
yenknip
Active Participant

I wouldn't label this as a CAR. A deep copy should duplicate everything.

I could agree with adding a config switch to default the copied label to hidden / visible

_____________________________
- Cheers, Ed
X.
Trusted Enthusiast
Trusted Enthusiast

I am a big fan of options, but I haven't found a single use case where I would have wanted to propagate the label down the wire. I agree that there might be some debate as of which side of the wire should keep the label, but in a sense, the natural LabVIEW data flow direction being from left to right (unless there are some localization variant?).

 

In fact, the natural behavior, in my opinion would be the following:

 

1) if the structure I add to the diagram CROSSES the label, duplicate it so that it appears on both side of the structure

2) if the structure is to the right of the label, leave the label to the left

3) if the structure encompasses the label, move the label to the right

 

Guess what? This is what LV does already! So, my bad, there is no logical problem with the current behavior. I just did not realize that I was just shooting myself in the foot by pasting through the wire label...

 

EDIT: actually that is not always true. Case 2) sometimes fails (as in fact shown in my first post). I was able to reproduce it after I realized the inconsistency between my two posts. So here I am it again:

My suggestion: make sure the label inheritance works according to the rules above.

 

Illustrations:

 

Case 1:

 

ScreenHunter_001.jpg  should (and does) result in:  ScreenHunter_002.jpg

 

Case 2:

 

ScreenHunter_003.jpg should (but doesn't) result in: ScreenHunter_004.jpg

 

Case 3:

 

ScreenHunter_005.jpg should (and does) result in: ScreenHunter_006.jpg

 

AristosQueue (NI)
NI Employee (retired)

There is no right solution here. X argues for his position. It's no more valid than the one LV has today, despite his assertions to the contrary. The real answer is don't label wires... they're too ephemeral. It's like attaching a comment to the whitespace in a text programming langauge and then complaining when you type somthing that the comment gets put both above and below the new command.

 

Labels on wires is a flawed idea, one that I didn't see as being workable when they were first asked for. I stayed completely out of the design for them because I never came up with anything remotely usable and I didn't want to derail those who were so passionate about introducing them. But they really are a flawed entity, and I don't think it has anything to do with the implementation. They just aren't good things to label. Label their source nodes, their source shift registers, their source whatever. But not the wires.

X.
Trusted Enthusiast
Trusted Enthusiast

With all due respect, I don't think you can speak for all LV programmers out there. I have diagrams where I've got to label some of my wires to get to the level of legibility of a text language. And please don't tell me that this means my VI is too complex. For what I do, unfortunately, complexity is part of the daily routine.

Example:

 

ScreenHunter_008.jpg

 

This being said, I am not making a big deal of this feature. Although my post is long winded, if you read it carefully, and in particular the final edit, you'll see that I conclude there is some inconsistency in the way LV decides to split or not the label. If I get too close to it with the structure (but how close is close?), it is split. If not, it is not. Again, no biggie.

X.
Trusted Enthusiast
Trusted Enthusiast

Another example of the potential annoyance of the current rule.

Here is the original diagram:

 

ScreenHunter_001.jpg

 

Note the integer wire labeled "#IRF/2 (k)". I will now insert a compound arithmetic operator just adter the "IQ" ouput of the Quotient and Remainder function. That output happens to be the labeled wire. Here is the result:

 

ScreenHunter_002.jpg

 

See the label underneath the operator? It belongs to the microscopic piece of wire to its left. I do not need it. And it is extra work to get rid of it...