Oh I don't mind the wrap-around. I just would like index 0 incremented to be 1 in all cases where there are at least 3 elements. Increment and decrement are interchangable for rings and enums with 0-2 elements
Frankly, I never ever use these as UI elements, and for my non-UI rings and enums, I usually just click and select from the list, so I never even noticed this and I don't really find this to be an issue.
I disagree with the suggested behavior change. Enumerations and rings are conceptually different than numeric values. The up/down buttons should (and do) cycle through the item list, rather than incrementing/decrementing the numeric value associated with the item. (In fact, with sparse rings, the values of the items are not necessarily sequential, so incrementing/decrementing them makes no sense whatsoever).
For example, if I have a list of items that contains "A, B, C" (displayed from top to bottom when you pop up the list) and I'm currently viewing B, clicking the "up" button to get to A seems perfectly intuitive.
Christina Rogers Principal Product Owner, LabVIEW R&D
I agree with your analysis of "what is expect Behavior BUT do not agree that it is " Correct"
LabVIEW arrays are Col- Row Because that is the way USERS think.
LabVIEW itself- breaks programming paradigms to become "approachable" to a non-programmer. YES your point is that these "Increment" and "decrement" icons SHOULD be intuitive.... I suggested that they should be consistent and correct.
Jeff K. Thought it was worth a kudo. And I feel it is the correct behaviour.
++ means the index increments---- the user may do other things to the object to change the value property. Yes there is a difference between users and programmers- I can live with either choice but, pressing a button with "^"to me means ++- or at least "go to the next higher choice"
I understand that LabVIEW should be approachable---- but it should be correct too .... Increment means "next higher" and the graphics between "Increment" buttons should not be smaller when the effect is reversed
In my car, the gas and brake pedal look the same. However, when I press the gas pedal, my car accelerates. When I press the break pedal, it decelerates. I guess my point is that users are accustomed to some level of inconsistencies (and that is an understatement!). I think we all can leave with the current status 🙂
PS: I actually did not understand what you were talking about initially, my apologies for that...
would this break old code?-- NO! that would be intolerable. I imagine an implementation that corrects this behavior above a certain version. Yes this means that us power users will say things like "Oh drat those buttons went fixed in 2010" similar to how we say "Pink error wires, Ugh!" and shudder but move on.
In favor of consistency, I also think that the increment/decrement buttons should always behave the same. Every time I have the choice to switch the ENUM value, I end up clicking the wrong button and need to reposition the mouse as well as click another 2 times.
I do NOT believe that ENUMs behave differently than eg. array, just imagine:
When you press the UP button on the array element, of course the index increases, but ALSO, all the array elements move UP (and the previous top-most element gets hidden). When you compare this to the ENUM selector, if I want select the next choice, I want to "move" the possible list up -> hence I push the UP button - BOOO - again ... WRONG direction hit... (because the previous element gets selected)
It would be so nice if the ENUM (and the RING) behaves the same as the other numeric types. Thus, Kudos!
