Feature request: Editable string (char*) field

[Redferne]

It would be awesome to enable support for editing a char array with configurable length. It would also need to add constrain support per character. Such as 0-1, 0-9, 0-9+a-f and text using (a-z).

I'm thinking a usecase where first click of encoder puts the field in edit mode (as usual). Now left and right selects character to edit. Next click enables edit of that character (within constrains). User uses left + right to cycle to new character. User clicks again, new character is stored in array, jumps back to select character. Here user must either do left or right to select new character to edit, or if the user just clicks (again) it will jump out of edit mode and back to menu.

Ideas, comments anyone? Please chime in, for my implementation this is the last missing piece 😊

Thanks for a great library!

[neu-rah]

this is a long waited feature... guess we will implement it this time :D

ABCD[E]FGH <--- we can use this style of "cursor" (it will work on all devices i think) and because we can at least move forward (minimalist 2 button menu) it would be sufficient even on minimalist devices (like single line LCD with 2 buttons)

changing to ABCD>E<FGH on character edit mode

[christophepersoz]

I'm still quite interested on this feature too ;))

[neu-rah]

hey! I've created a new textField branch https://github.com/neu-rah/ArduinoMenu/tree/textField that includes initial support for editing text along with an example. No macros support yet.

it uses per character validating strings, because strings are easy for users to setup and can be reused.

I end up going straight to the problem, leaving behind some previous considerations of character edit being some sort of menu and character selection being some sort of single line menu (not implemented yet). It turned up to be the correct decision, i think.

the character cursor is still [x] >x<, to be used with serial. But text edit cursor draw should latter migrate to output devices because they are specific to out devices, some can use underline cursor or colors instead of that []>< thing.

enjoy :D

[neu-rah]

alternative: on enter move to editing next character and exit if enter again with no character change or end of field reached.

preferences?

[christophepersoz]

On my side I prefer : Move to the character you want to edit (or the first one if the field is empty), Enter to edit it, Enter to validate the change Move to the next one or go to the last char of the string followed by a special char (non editable) which is the one to validate all the changes. Is that possible ? FIL>E<NO1 ✅ (Check is the special char for example) I like the idea of underscore on graphic display to select the right char or an invert when on char change mode (u8g2 allows that) and underscore on edit.

[neu-rah]

using special chars for backspace and edit end was one of the ideas but they can be messy among multiple devices and fonts

[christophepersoz]

Assuming that the string have a predefined length, I'm not sure that the backspace is needed, you can have blank char to remove the undesirable char in the string. Maybe there is a common char in charset that can be used for edit end. What do you think ? An another possibility, long press to exit edit mode

[neu-rah]

using special characters that can work between serial, ansi terminals, LCD, TFTs, web and some other crazy devices from the very long list of supported devices and some possible future new displays (like led array) would be a problem. It would provide a nice way of ending edit or backspace for sure... maybe we can support both and use it when the device supports a nice character (by some config or custom object), but still think this can not be imposed for every device by the core lib.

p.s. or maybe some field types can not be used on every devices, this edit field with per character validation can even work on seven segment arrays :D by making the current digit blink at different rates

[neu-rah]

ohh and long press is a button (or encoder) thing, serial needs another method.. still i think the current encoder driver sends an escape for long press (not sure if it is still working on v3)

[christophepersoz]

Hmmm it worth to give a try for the encorder driver! ;) I'm currently implementing your v3 on a new project, which works with an encoder and a small oled display. I could try that mid September if needed.

[neu-rah]

implemented validators without length reinforcement validators are used by character index but can cycle, this allows a single validator for all field or repetition of patterns like IP numbers. still on dev branch

[neu-rah]

dev branch text edit field should be complete with macros, validators, cursors. Included on some examples.

compatibility if slightly offended:

• printTo accepts/requires an extra parameter, needed to calculate edit position and draw overlay cursors as in LCD's. All other cursors are inlined either by printing characters (serial) or by changing colors (gfx and ansi).

• fontY should now account for fontMarginY (removed fontMargin calculations from driver).

also removed serial multiple redraw bug when using raster devices as U8G's (added new style rasterDraw).