Roku Developer Program

Developers and content creators—a complete solution for growing an audience directly.
cancel
Showing results for 
Search instead for 
Did you mean: 
JohnBasedow
Level 7

Bug?: roSearchScreen and roSearchScreenEvent::isButtonInfo()

The API docs say this about the roSearchScreenEvent's isButtonInfo() function:
http://sdkdocs.roku.com/display/sdkdoc/ ... creenEvent
The Info remote key was pressed. This is only emitted for the search results on the right side of the screen.


Except if you have one of the buttons on the lower part of the screen focused, and hit the info button, the isButtonInfo() event gets fired, and the msg.GetIndex() returns 0.

Because of this, and the lack of a way to tell if the search results list is focused, there is no way to tell if the combination of the isButtonInfo event and msg.GetIndex() == 0 is actually occurring over the search results list.

If msg.GetIndex() returned an invalid value, or a special value based on the button selected, that would be more useful, but as it stands, this will cause unwanted side effects for channels using the info button on the search screen.
0 Kudos
3 Replies
EnTerr
Level 8

Re: Bug?: roSearchScreen and roSearchScreenEvent::isButtonIn

Sounds like implementation bug, doesn't it?
Since documentation states "*" should "only emit[] for the search results" - and logically that's what makes sense too.
0 Kudos
JohnBasedow
Level 7

Re: Bug?: roSearchScreen and roSearchScreenEvent::isButtonIn

"EnTerr" wrote:
Sounds like implementation bug, doesn't it?
Since documentation states "*" should "only emit[] for the search results" - and logically that's what makes sense too.



You mean the Roku firmware implementation, and not mine, right?
0 Kudos
EnTerr
Level 8

Re: Bug?: roSearchScreen and roSearchScreenEvent::isButtonIn

"JohnBasedow" wrote:
You mean the Roku firmware implementation, and not mine, right?

Yes, that firmware does not act as it should've.
0 Kudos