7 years, 9 months ago.

Any thoughts on alternate keypad structures?

First of all David, thank you for all of your excellent work! Appreciated.

I'm looking to modify this library to allow for selectable keypads one being a simple cellphone style numeric pad, and the other being a restricted qwerty. My app uses a lot of screen real estate, and I need to make a narrower keypad, with only block alpha, shift would give symbols/punctuation.

I see these being named arrays kind of like a font, that you could call on instantiating the keypad ...

(admitting that I'm outside my comfort zone, as I suck at object oriented coding)



Question relating to:

Onscreen QWERTY keypad for RA8857 based display. Uses the resistive touch panel. keypad, RA8875, Touchscreen

1 Answer

7 years, 9 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,

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

then just register NumberPadDef with the keyboard handler software.


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.

Accepted Answer

Thank you for the quick response David. Your keyboard struct looks similar to what I had in mind. I had already put the X,Y,W,H in place, as my 480x272 display is divided vertically into controls on left side, and sensor displays on right side. The restricted keyboard would have to fit into 240 wide... Can we say stylus?

I had only thought as far as to have the whole keyboard array in a single pointer, but separating it for shifted/unshifted makes a lot of sense.

I'll monkey around with this and let you know how I fare.

Appreciated as always.

posted by Michael Ball 02 Mar 2016