8 years, 2 months ago.

hi Michael, thanks for the kind words. But for C++ I'm mostly outside my comfort zone as well, usually on the fringe of "it works, but I bet someone more skilled could make it a lot better...". In the pure c-world, my confidence is much higher.

The keypad was more or less an afternoon project, and it is rather restricted (e.g. not all supported keys are supported). There are some kinds of hard-coded behaviors as well.

OK, enough apologies and disclaimers. Can you morph it to meet your needs? Sure. What issues quickly come to mind? Just thinking out loud:

• it scales the key set to the display width, and you might instead was to construct the keypad with additional information (x,y,w,h) parameters.
• KROWS is a #define to set the number of key rows. This too might be best served with parameters.
• The keyboard layout is a simple array of pairs, ending with the 0,0. There are some "magic" values in there coded to use a symbol, and parsed to translate into selecting the alternate key set. I could next imagine this is also a parameter - as a pointer to the table.

Now, having glanced at the code to get this note created, a few additional thoughts:

• Embed all the possible keyboards in to the library, to the extent that they are useful for many system.
• Provide a pointer to the keypad definition in the constructor, or a separate API, as noted above.
• Create a totally separate derivative, one for each special keyboard type.

As a first attempt, and because I only have the 480x272 display, I imagine this keypad would simply stretch-scale to 800, and that might not be what you would like to see.

In the context of "named arrays", I'm now thinking of a bit more complex structure:

typedef struct {
    loc_t x,     ///< left edge of keypad. typically 0 to +n. negative is translated to zero. 
    loc_t y,     ///< top edge of keypad. typically 0 to +n, and more typically in the bottom half of the screen height.
    dim_t width, ///< width of keypad. be sure that the keys can fit. negative is translated to screen-width.
    dim_t height,  ///< height of keypad. be sure the number of rows will fit, based on the desired key height.
    int rows,          ///< number of rows to show.
    char * keydef1,
    char * keydef2
} keyboard_t;

an implementation might then be:

const keyboard_t NumberPadDef = {
    100, 100,
    200, 200,
    4,
    &NumPadLayout,
    NULL 
};

const char NumPadLayout[] = { data similar to the qwerty example };

then just register NumberPadDef with the keyboard handler software.

    kp.SelectKeyboard(&NumberPadDef);

As it exists, it gets a string, which could now be restricted to numbers, and you could atoi/atol/atof. But as a numeric keyboard, you would like to not allow entering "-123-45.678", which would take some additional intelligence.

I don't know if any of this helps paint (at least one) picture of what might be a next evolution.