Use ASCII symbols for control

[ShishkinDmitriy]

Right now MenuItem and LcdMenu have a bunch of methods:

• virtual void up() {};
• virtual void down() {};
• virtual void enter() {};
• virtual void back() {};
• virtual void left() {};
• virtual void right() {};
• virtual void backspace() {};
• virtual void typeChar(const char character) {};
• virtual void clear() {};

Proposal is to have 1 method bool handle(const char c). Name can be different.
It will decrease number of virtual methods.

Both printable and control symbols (https://en.wikipedia.org/wiki/ASCII#Control_code_chart) are suported in ASCII table, so it's possible to use just 1 char, 1 byte is enough.

#define LF 10 // Enter
#define BS 8  // Backspace
#defina ESC 27 // Escape
//...

bool handle(const char c) override {
  if (isprint(c) { // Printable char
    return typeChar(c);
  }
  switch (c) {
    case LF: return enter();
    case ESC: return back();
    case BS: return backspace();
  }
}

Need just reserve 4 symbols for arrows - looks like there were no stadart way for them when ASCII was created. Device control 1,2,3,4 looks pretty good for this.

Also one of Charset item implementation can be simplified to have lower char and upper char:

• [32, 126] - for all printable
• [48, 57] - all numbers
• [65, 90] - all uppercase letters A..Z
• [97, 122] - all lowercase letters a..z
• and so one

[forntoh]

if (isprint(c) { // Printable char
return typeChar(c);
}

Looks overall nice, I see one potential issue with the above code, what if I want to use printable chars to control the menu e.g. with WASD?

The library was mane in such a way that the way you control it is up to you, whether you use push buttons, keyboard, rotary encoder etc. the library would just work, you would just read your command from your desired input and perform the desired action on the menu. It is more intuitive to the person that has their input method to just call those humanly readable functions, so as far as readability/understandability/maintainability goes to those using the library, I feel like it's better to give explicitly named functions.

Also one of Charset item implementation can be simplified to have lower char and upper char:

Yes this is true, but in some cases, I want only some characters to be allowed, for example I want only odd numbers 13579, I can't pass an upper and lower bound, I have to explicitly define it.
Also take note that the encoding of characters depends on the display you're using, so the display might not show the same ascii characters as in the table. I can pass in e.g 0x7E but it shows completely different characters on different displays.

[ShishkinDmitriy]

Let me explain with more details.
Right now the number of metods on base MenuItem class depends on most 'rich' item. Method backspace exists only because of ItemInput. But for example ItemCommand also has method backspace but do nothing.

Just imagine if some item wants to handle delete command for example, or home or end commands. We have to add one more method into base class. It means the most 'simpliest' item implementation depens on the most 'rich' item implementation.

Existing methods will be not deleted, they will become protected, they are usefull for overriding. But question is about public API of MenuItem. Instead of having several methods (that you may have to add new methods) it will have only 1 handle method that accept 1 byte, which means possible 256 values, printable are only ~100. In case of new functionality you just need to find free command address.

So in case of new item implementation, if you want for example implement super-mega VIm-like navigation item, it will not affects previously written implementations.

Also I would suggest similar layesr as DisplayInterface but for input level. Different implementation will handle different inputs - keyboard, WASD, Rotary encoder, maybe 8 dedicated buttons.

[forntoh]

Closing this as it is now Live as from v5.0.0, thanks @ShishkinDmitriy