label auto-numbering

[cy...]

hello forum

given certain circumstances, the auto-incremental function for labels may lead to entirely different meanings. maybe sticking a non-printable character or a delimiter next to autonumber can solve this?

for instance, delimiter "- " in this case would make it even worse, but a non-printable character maybe... 

1st label: number: 0 to 1 

2nd label: number: 0 to 1 - 1

3rd label: number: 0 to 1 - 2

and so on

[RavensFan]

I don't understand your idea, nor how your image relates to it.  What is odd is that you have some of the wires missing in the image.

What exactly is the problem you are trying to solve?

[cy...]

@RavensFan: sorry for not circling the issue in the attachment

current auto-labeling scheme for new controls and indicators adds a number to the right end of the label text for cases with identical label text, or increases the label text number by 1 if it contains number at its right end. The attachment exhibits the "number: 0 to 1" function's new indicator label text being changed to "number: 0 to 2" with the current incremental scheme, which by itself carries a different meaning. 

current scheme

number: 0 to 1 (1st label)

number: 0 to 2 (2nd label) 

number: 0 to 3 (3rd label)

new scheme

number: 0 to 1 (1st label)

number: 0 to 1 <d>2 (2nd label)

number: 0 to 1 <d>3 (3rd label)

<d> = delimiter, either a non printable character, "- ", "()", "[]", etc

This idea is to use a non-printable delimiter to identify the incremental digit from the user label

[RavensFan]

What is the benefit of the non-printable character?

Copy and pasting controls gives you the number to help distinguish them, but only rarely are the duplicates going to be exactly the way you want them.  It is even more unusual to have controls that have a more complicated numbering arrangement at the end like "0 to 1".  Since you likely need to edit the label for every new copy of a control, what does the non-printable character to for you?

I'd argue having that non-printable character is dangerous because there is nothing obvious that it exists in the label.  Someone searching for a control with a label of "0 to 1" will be surprised when they can't find the match because the label actually has the non-printable character in it.

[cy...]

the example is given 0 to 1, as an example, it applied for other cases where the last 'word' of the label a number.

the non-printable character serves as a delimiter to separate the number at the end of the user defined name from the auto-incremental numbering. When you are searching for an object based on its name, the delimiter character will not be within the searched name, <name ending with number><delimiter><auto-incremental number>, as it preserves/prevent the user defined name from auto-numbering.

That's the point of having the delimiter, so that the name cannot be accidentally/unintentionally changed by LabVIEW itself.

[AristosQueue (NI)]

cy... I see your goal, but I think the current autonumbering is mostly there so you can keep straight which is the original and which is the copy while you work, not to provide a final name for the copy. Yes, there are some cases where you really do want N copies of the same control, but in most, you're going to need to change the label manually to something entirely other. I don't think there's a lot of benefit to making the number be a separate part of the label (regardless of the method of isolation) because it's more ephemeral than not, in my observation.