Customizable names for Count terminal (aka N) and Iteration terminal(aka i) in Loops

[X.]

Need I say more?

I do a lot of math formula transposition from my written notes to LabVIEW where matrices or vectors are involved.

I usually try to use different index names for different dimensions and most of the time, the size of vectors or matrices are different, so having three nested loops with all sizes called "N" and all indices called "i" doesn't help with legibility.

It would be fine (somewhat) if one could add labels to the count and iteration terminals, but we can't. And labels on wires are not as visible.

And since a picture is worth 1,000 words:

[AristosQueue (NI)]

> I am not asking for Chinese or Arabic character support, mind you...

But I'm sure someone else is.

[AristosQueue (NI)]

As a member of LV R&D, I say this is a completely doable feature and if enough people wanted it, I don't see any problem with it.

As a user of LabVIEW, I don't like it at all.

I've long thought we'd be better off getting rid of the letters entirely. They aren't graphical and they aren't localized.

Obviously the particular glpyhs aren't what they would be, but that would be better than N and i (and definitley better than P and C, which don't even have the justificiation of being arguably universal mathematical symbols).

I'm guessing those of you on this thread would not be a fan of this.

I have to say, changing the text in those squares seems a bit weird to me... it's like requesting to change the icon on a subVI for one particular invocation. Akin to something like this:

Changing the iconography of an invocation of any node -- including the For Loop -- makes it harder for me to know what a node is doing. If you put that "K" node in the middle of a loop somewhere, and I'm busy looking for the "i", it's one more needless variation.

[Intaris]

Well I for one think the "i" (Insert name here) is still visually distinct enough to be found just as easily as the default terminal. If the argument of being hard to find stands for finding a "k" in a for loop then surely the same argument appleis for an "i"?.  Ia lso find the "i" terminal hard to find sometimes but I wouldn't couple it with this idea for "i" terminal customisation neccessarily.

Ona  side note: how about an ability for all structures to highlight (flash?) their terminals (stop terminals, Iteration coutners and so forth) automatically on selection? 

[X.]

@AQ: you are not using sarcasm in a very efficient way... but you are getting there.

I have not mentioned changing the glyphs in primitives. When I want to do that, I create my own VI, copy the icon of the primitive and modify it for the new VI.

I have explained why the feature I was suggesting would be helpful for me, so I don't think there is any point in reiterating it. I have also explained elsewhere why I was having problems with array primitives. This is really the same reason: it is easier for me to transpose an algorithm I have come up with on paper into LV code, if the LV primitive are either functioning naturally or in a self-explanatory way (for me, which might not make it necessarily universal) or read as close as possible to the notations I am using.

In short, you are saying that I should have the mental flexibility to overcome the notational difference, or maybe that I should only use N and i as variable names. And certainly not P and C? Boy, things have changed!

If this is the way things go, I have no pretention of changing them...

PS: written tongue-in-cheek...

[Manzolli]

@Intaris side note: Liked! How about a double click on the border to highlight their intrinsic terminals?

[_Y_]

I would not appreciate reading a code with customised terminals of standard functions. It looks for me as programming in a text language:)) There are other methods. For example, use labels to do loops recognisable (and modern LV has even Subdiagram Labels).