Improve Select button response when Long Press is enabled during CPU-intensive apps (WFM) #1304
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There's still some room for improvement on the select key response when "long press" is enabled, but this change basically resolves the issue with the frequency entry screen not being accessible in WFM mode due to missing "select" key presses.
Looks like several changes in this PR, but most of them were just moving code from the header module to the CPP module, and changing "0' to "false" for bool types.
When Long Press is enabled, the real button press is masked until either the button is released or the long press delay is reached. When the button is released, a simulated button press occurs. Previously, the simulated button press would be cleared on the next timer tick, so the EventDispatcher (which calls state()) might miss it. Now, I have added a "simulated_pulse_" flag to make sure that EventDispatcher sees the simulated pulse before clearing it.
I might have a better fix tomorrow, but this was a simple patch for now that gets the frequency entry screen working again in WFM mode after #1298.