Why is that I can't use 0 where the 16 is now? I just spent a frustrating hour checking wiring, swapping buttons around buzzing things with a meter - when I took out the 0 and put in 16, things worked.
Nope, no go.
Nevermind, got it working with 16, on to the next stage ...
case 0: never runs. key never equals 0.
// read the keypad
char key = keypad.getKey(); // reading the keypad
if (key) // same as if(key != NO_KEY)- did something change?
{
priornumPressed = numPressed; // save prior button push
numPressed = key; // load the array with the key character
updateDisplay = 1;
digitalWrite(ledPin, true); // Flash a light to show transmitting
Serial.print ("Button: ");
Serial.println(numPressed); // for debugging only
delay (50); // need some delay or seem to miss key presses
digitalWrite(ledPin, false); // turn off the flash of LED
}
If it matters, running a Bobuino 1284P under IDE 1.8.5
that's indeed the result of limited thinking outside the box in the design of the library where the getKey() method returns a char which is the underlying type of what you put in the matrix. The expected use was probably to return directly the label that is written on the key as we see in all examples.
Because the method also needs a way to tell that no key was pressed the author had to sacrifice one magic value to mean no key was pressed and 0 was chosen.
But sometimes it's better to return something else that makes more sense for computation without having to convert ASCII to some numeric value (for example in my answer there I could have hardwired pins number to each key or as done there index+1 of the pin in an array) and in that case you get to deal with not being able to use 0 (and sometimes you find this the hard way loosing hours... )
Serial.read() for example chose to return an int at -1 to signify there was nothing to read, so you actually get 2 or 4 bytes back from the method call and this way you can safely know there was nothing to read and can still receive the full range of bytes values (which is critical of course for read).
The library could easily be updated to return an int and changing NO_KEY to an int and valued -1. That would work transparently for all properly written codes that check against NO_KEY to see if something was pressed, but would break codes where developers took a shortcut and based their programming on the fact that NO_KEY is 0 and wrote if (! kpd.getKey()) { ...}instead of comparing with NO_KEY...
)