Detecting Keypress Release
I added a feature to our app to detect "long presses" - when the user is holding down a directional key, the focus keeps moving until the key is released. Problem is that sometimes the roku does not ...
Forum Discussion
"RokuMarkn" wrote:
I was referring to how the remote itself behaves. The events delivered to Brightscript use a different paradigm. If you look at the remote through a cellphone camera, you will see that while you hold a button down, the remote is sending continuous codes. (Well not actually continuous; it repeatedly sends 180 ms codes with a 30 ms gap between codes.) When you release the button it stops sending. The firmware sends one press event to Brightscript when it receives the first code, and synthesizes a release event when it fails to get another code in the expected time.
Right, that's a good one - preview through phone's camera. Subject to whether the camera has an IR filter - e.g. my iPhone5s can't see the IR LED at all - then iPhone4 sees it, very bright - then iPhone6 sees it again, as dim violet.
A few years ago i was into IR codes and remember Roku remote actually sent 2 distinct NEC codes per button... but since you say there is no "key up" IR code, it might be the two codes might been "key-down" (sent once), followed by "key-down-repeat" (multiple times). Which ummm... doesn't seem to make a difference for this thread.
Given that, seems it must be some issue with the firmware, doesn't it? Like either keyUp event does not get synthesized or gets dropped from the queue. There might be something in BradC's method (e.g. imagine waving remote to the side mangles the IR repeat code enough to confuse the receiver) but i can't reproduce it in RokuTV's main screen - BradC, does it have to be in B/S app?
