Key Up/down direction when selecting a GEMSelect item

[tangiblewaves]

First, GEM is simply great! I used it in a few projects successfully.
Today I encountered the following issue: When editing a GEMSelect item, the value is incremented by the Key down button and decremented by Key up; this behaviour is different to I know it. This is the first time I used the version 1.6 ; previous GEM versions seem to work differently here. Was something changed here? Or did I miss something? Same behaviour can be seen with the new GEMSpinner (BTW: Great you introduced it! Definitely worth the space!)
The menu item selection however works as expected (Key up goes up in the menu).
I tried invertKeysDuringEdit(), but without success.
Any help would be highly appreciated, thanks!

[Spirik]

Hi, @tangiblewaves !

Thank you for using GEM library!

invertKeysDuringEdit() method affects only edit mode of editable variables (such as char[17] or numbers) when navigating through characters of a single digit. It does not affect selects and spinners.

GEM_KEY_UP was always associated with going to the previous option in selects (so decreasing the index in an options list) and GEM_KEY_DOWN to the next one (increasing the index in an options list). And this behavior was preserved in spinners as well. I can see that this is indeed can be a problem when using push-buttons as an input with range spinners (however works naturally with a rotary encoder as an input device).

Thank you for bringing this to my attention. I should've thought of this earlier:(

Will try to come up with proper solution to this. I do not necessary think that expanding effect of invertKeysDuringEdit() to selects and spinners is a good idea (at least from the backwards compatibility standpoint), but separate method that affects only spinners and selects could be.

[Spirik]

I think I got it. I will modify default behavior of spinners for push-button input method (so you won't have to call additional invert methods when using push-buttons as an input device), and make them react to invertKeysDuringEdit() in a way that they currently operate (so users with rotary encoders won't notice a difference in behavior, because they most likely already call invertKeysDuringEdit() any way). That change won't affect selects (so their behavior will remain the same regardless of invert option).

I will include this fix as a part of an upcoming release (hopefully in a couple or so days).

[Spirik]

Should be fixed with the 1.6.1 release. No need to call invertKeysDuringEdit() when using with push-buttons as an input method.

[tangiblewaves]

Wow, that went quick! Thanks so much - works great! Additional info: First, I was assuming a changed behaviour to previous GEM versions, but actually I had simply tricked myself - the up/down buttons were mounted horizontally, therefore, the increment/decrement behaviour was not irritating. But in the current project, up/down buttons are above each other, and just by this difference, the behaviour, that the lower button increments values was quite irritating ;-)

Only one more question: It works great for spinners now, but not for Selects (as you have announced already); but I consider this still as problematic in certain cases; I'll give an example: The GEMSelect offers a list of numbers plus an entry named "none". So the user expects the same behaviour as with the Spinner (it's mostly numbers), but now, Spinner and Select are behaving differently. I'd say there are cases where GEMSelect values are arbitrary values and the behaviour might not be noticeable, but... I think you get the point ;-)
I'm not sure how and when I should apply invertKeysDuringEdit() to workaround this; before / after showing the menu? Sorry if I have overlooked it.
THANKS!

[Spirik]

I see your point, but I decided not to extend effect of invertKeysDuringEdit() to selects on purpose. Since the order of options in selects is explicitly managed by author of the sketch (unlike in spinners), it is within author's power to change it as they seem fit, say for more natural feel in accordance with input method of their choosing (or by any other consideration). And secondly, I decided not to mess with the default behavior of selects for backwards compatibility with already written sketches (authors of which may update the library and won't expect their selects behave differently all of a sudden).

Primary use case for invertKeysDuringEdit() is with rotary encoder as an input method. Generally it is called in setup() before menu.init();, however that does not really matter: it can be switched on and off dynamically almost at any time (It can be adjusted during sketch runtime in Setting menu page of Encoder and Todo List examples).

[tangiblewaves]

Completely agree that a change of invertKeysDuringEdit() would break backward compatibility; makes totally sense not to touch it of course.
And you are right, I'm free to adjust the order of the Select items according to the desired behavior.
So all is good! Thanks again, excellent!

[Spirik]

Thanks once again for pointing out this behaviour. Closing issue as resolved.