Strange behaviour of I2C LCD w/keypad

I'm slowly solving some little quirks about this Matrix Orbital LCD/Keypad controller
This code works great, it never misses a keypress:

 do{
   getkey  = lcd.keypad();
   if (getkey != 0) break;   
 //  lcd.setCursor(13,2);  //COL, ROW
 //  lcd.print(FlowSensorCount);
 }while(1);

...but with this code, I have to sometimes press a key 3 or 4 times to get any response.

 do{
   getkey  = lcd.keypad();
   if (getkey != 0) break;   
   lcd.setCursor(13,2);  //COL, ROW
   lcd.print(FlowSensorCount);
 }while(1);

Both codes are just waiting for user input on any key. It'd be nice to show a little feedback on the screen while I wait, but it's a major problem if they have to push a key 3 times to get it to respond.

The print commands are interfering with the keypad so you must print as little as possible.

try this; it is definitely not 100% robust but as it will only print the FlowSensorCount if it is changed it can spend far more time reading the keypad()

int prevCount = -1;  // assuming FlowSensorCount cannot be negative

do 
{
  if (prevCount  != FlowSensorCount) 
  {
    prevCount  = FlowSensorCount;
    lcd.setCursor(13,2);  
    lcd.print(FlowSensorCount);
  }
  getkey  = lcd.keypad();
  if (getkey != 0) break; 
} while(1);

robtillaart:
The print commands are interfering with the keypad so you must print as little as possible.

try this; it is definitely not 100% robust but as it will only print the FlowSensorCount if it is changed it can spend far more time reading the keypad()

int prevCount = -1;  // assuming FlowSensorCount cannot be negative

do
{
  if (prevCount  != FlowSensorCount)
  {
    prevCount  = FlowSensorCount;
    lcd.setCursor(13,2); 
    lcd.print(FlowSensorCount);
  }
  getkey  = lcd.keypad();
  if (getkey != 0) break;
} while(1);

Thanks, I'll try this out. FLowSensorCount changes at a max rate of 16 pulses per second, so do you think this should be pretty dependable with the keypad response, then?

FLowSensorCount changes at a max rate of 16 pulses per second,

The human eye cannot read such fast changes, a variation of the above could be timebased refresh of the LCD :

twice per second refresh

#define LCD_REFRESH_FREQ     2  // change this to your need, may even be smaller than 1 but must be > 0
#define LCD_REFRESH_DELAY   (1000/LCD_REFRESH_FREQ)

unsigned long lastRefresh = millis() - LCD_REFRESH_DELAY;   // subtract to force lcd.print first iteration

do 
{
  if (millis() - lastRefresh > LCD_REFRESH_DELAY) 
  {
    lastRefresh = millis();
    lcd.setCursor(13,2);  
    lcd.print(FlowSensorCount);
  }
  getkey  = lcd.keypad();
  if (getkey != 0) break; 
} while(1);

This time based refresh still didn't work: About 1 out of 6-8 keypresses would be missed. I got to looking, I found if I took out the setCursor line, it worked, even though it was still writing the Sensor val line.
So I looked in the library at the setCurosr and found this:

void LCDI2C::setCursor(int line_num, int x){
	
	Wire.beginTransmission(g_i2caddress);
	Wire.send(0xFE);
	Wire.send(0x47);
	Wire.send(line_num);
	Wire.send(x);
	Wire.endTransmission();
	delay(100);
}

...I commented out the delay(100), and now it works fine! I don't know if/why that's there, but unless I find trouble somewhere else I'll just leave it commented out.

the delay(100) is probably there to give the hardware time to do the internal administration.
delay(100) = 0.1 second and this seems fairly long to me.
Please check the datasheet how much time is needed.
Maybe it should be delayMicroseconds(100);