You are reading a single comment by @d3nd3-o0 and its replies. Click here to read the full conversation.
  • I'm aware of debounce within in the setWatch function, and its default value of 25 for buttons. However, in the source code in function

    void btnHandlerCommon(int button, bool state, IOEventFlags flags)

    It doesn't propagate the button press event if its waking up the display and it includes code to catch the keyUp/release, to not propagate. Considering the nature of keyUps and KeyDowns that i've witnessed with debounce set to 0, is it not true that there will be instances where key events ARE propagated because of the debounce issue when a button is pressed to wake from LCDOff state?

    I'm saying all this because I think i am noticing some sort of inconsistencies with whether my app processes the key press from wake or not. Eg. PizzaTimer app, if i set a long timer (eg. 1 hour) then half way through it press the middle button, it seems to stop the timer at some point.

    Another example of inconsistency can be observed in the 'launch' app menu. If i go into that menu, allow the screen to turn off/timeout and then press 'down'/BTN3, the menu will have gone down one entry, but if you try it again, it doesn't do that behaviour. You have to relaunch the 'lauch'/launcher app and repeat, to see it again.

    Just curious. (For the time being I make sure I press BTN1 not BTN2 when waking my watch during a long timer with 'PizzaTimer' App)

    EDIT:: I can recreate it, its not related to 'time' .. its related to how fast I press the button mb. When i press it fast in and fast out, it sometimes propagates to the app.

    Conclusion: I think the LCDTimeout wake feature should properly 'consume' key presses, handling any issues with debounce, so that the behaviour is consistent.

About

Avatar for d3nd3-o0 @d3nd3-o0 started