GEM_VAL_INTEGER/GEM_VAL_CHAR edition

[fmafma]

Ok, I continue my suggestions ;o)

When the user enters edit mode, the cursor should be set to the lower digit. Up/down buttons should increment/decrement the digit, as it is done now, but overflow/underflow should be taken into account, and increment/decrement the left digit (and so on). Left/right buttons should select digit, as it is done now.

This way, when you are on the lower digit, you have the best resolution, but you can increment the entire value as high as you want without changing digit. And when selecting other digits, you can increment the entire value even faster (10/100/1000... times faster, depending on the digit).

This is how Agilent/HP lab instruments work, and this is very handy.

This would need to recompute the value at each key press, not only when leaving edit mode. This would be very handy, especially with rotary encoders.

Another nice feature would be to associate min/max/inc params with the item, to limit the amplitude and change it faster. Rollover or not should be an option.

[fmafma]

I would like to try to implement what I suggested above; could you explain me how the cursor is managed? I'm not sure to clearly understand the purpose of the virtual cursor...

[Spirik]

Consider you have 5-character long string (int/byte variable or chr[] doesn't matter - in edit mode it is represented by chr[] regardless). And only 3 characters can fit on the screen.

Then _editValueCursorPosition changes in the range [0..2] (length of the space on the screen) and _editValueVirtualCursorPosition changes in the range [0..5] (length of the actual string + one extra character for new digit).

So, basically, _editValueCursorPosition tracks visible position of the cursor on the screen, and _editValueVirtualCursorPosition - actual position of the selected digit in the variable being edited.

Implementation of your suggestion won't be trivial. So you would need to consider new behaviour of cursor in edit mode: it should jump to the less-significant digit upon entering an edit mode, and visible part of the variable should be shifted accordingly. When new decimal place is created (through an overflow of a lower digit), visible part of the variable should be shifted accordingly (either to remain visually at the same place or to jump right with cursor to leave space to accommodate new digit). No need for the extra blank space at the right end of the variable (currently used to create new digits) - new digits should be added to the left of the variable (that includes a special case of an - sign). And that just a few of the possible caveats.

So I would, probably, consider creating new type of variable GEM_VAL_SPINNER (or smth like that), that would take into account this new behaviour, so user will have an option to use it over default edit mode.

[fmafma]

Ok, I understand the purpose of the virtual cursor, thanks.

The Spinner is a good idea, it will be easier to start with a blank type, rather than modify an existing one. The behaviour is close to the SELECT type...