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: 
Highlighted
EnTerr
Level 9

bugs in roTextScreen component

With SDK examples, i wanted to start with something small and simple. Unfortunately they are not grouped or ordered in particular way, so i decided to go by source size. I started with "SimpleTextScreen", which is indeed simple to understand. But experimenting with roTextScreen component i noticed some inconsistencies and here is list of my observations:


  1. Bug: if SetText() supplied text is not long enough to be scrollable (i.e. bigger than the text box), pressing down button does not bring down to the buttons area and there is no way to select one of the buttons. This is a real issue when text is dynamically supplied and we don't know in advance how long it is (and yet want to be sure user is not stuck)


  2. Buglet: Text box does not get shown at all if there are 9+ buttons. I don't think that should be the case ever, since the name of the component is roTextScreen, presumably the text box is the lead singer.


  3. Buglet: Using addButton() after the screen has been show()n, adds the new button on top of the 1st button. The new button text shows on top of 1st button text and the text box shrinks, so it is trying to do something.


  4. Annoyance: Text box shrinks 3x faster than the list of buttons grows up, leaving bigger and bigger gap as the number of buttons increases - this leading to the gap being 1/4 of the screen with 8 buttons, while text box shows only two lines at a time, like so:
0 Kudos
6 Replies
renojim
Level 10

Re: bugs in roTextScreen component

"EnTerr" wrote:

  1. Bug: if SetText() supplied text is not long enough to be scrollable (i.e. bigger than the text box), pressing down button does not bring down to the buttons area and there is no way to select one of the buttons. This is a real issue when text is dynamically supplied and we don't know in advance how long it is (and yet want to be sure user is not stuck)

What device (or firmware version) are you using? I believe I noticed this with the 1st generation devices running v3.1 of the firmware, but not on the later devices running v4+. This bug is especially annoying because there's no way to get out of the text screen if the user has the original remote without a Back button.

-JT
0 Kudos
EnTerr
Level 9

Re: bugs in roTextScreen component

"renojim" wrote:
What device (or firmware version) are you using? I believe I noticed this with the 1st generation devices running v3.1 of the firmware, but not on the later devices running v4+. This bug is especially annoying because there's no way to get out of the text screen if the user has the original remote without a Back button.

All issues exists both on fw3 and fw5, that's why did not mention specific firmware or hardware - it is pervasive.
With older remotes in particular #1 is a pitfall trap - but no matter the remote, buttons below cannot be accessed in fw3.
0 Kudos
TheEndless
Level 7

Re: bugs in roTextScreen component

"EnTerr" wrote:

  1. Bug: if SetText() supplied text is not long enough to be scrollable (i.e. bigger than the text box), pressing down button does not bring down to the buttons area and there is no way to select one of the buttons. This is a real issue when text is dynamically supplied and we don't know in advance how long it is (and yet want to be sure user is not stuck)
"renojim" wrote:
What device (or firmware version) are you using? I believe I noticed this with the 1st generation devices running v3.1 of the firmware, but not on the later devices running v4+. This bug is especially annoying because there's no way to get out of the text screen if the user has the original remote without a Back button.

If you hit Select/OK on the remote, the focus will change to the buttons. Not very intuitive, but you shouldn't be stuck on the screen. My guess is that the assumption for the text screen was that it would only ever be used when there was enough text to require scrolling, otherwise you could use the paragraph screen. As a result, the up/down buttons were only coded to work when the text box requires scrolling. Either way, this bug has definitely been noted and reported to Roku (and I think even discussed on these forums at some point).
My Channels: http://roku.permanence.com - Twitter: @TheEndlessDev
Instant Watch Browser (NetflixIWB), Aquarium Screensaver (AQUARIUM), Clever Clocks Screensaver (CLEVERCLOCKS), iTunes Podcasts (ITPC), My Channels (MYCHANNELS)
0 Kudos
EnTerr
Level 9

Re: bugs in roTextScreen component

"TheEndless" wrote:
If you hit Select/OK on the remote, the focus will change to the buttons. Not very intuitive, but you shouldn't be stuck on the screen.

Not on firmware 3, it wouldn't.
And i only know the weird trick for firmware 5 because i read about it in SDK doc.
Which my mom (exemplary user) is not likely to do. Not obvious at all.
0 Kudos
TheEndless
Level 7

Re: bugs in roTextScreen component

"EnTerr" wrote:
"TheEndless" wrote:
If you hit Select/OK on the remote, the focus will change to the buttons. Not very intuitive, but you shouldn't be stuck on the screen.

Not on firmware 3, it wouldn't.
And i only know the weird trick for firmware 5 because i read about it in SDK doc.
Which my mom (exemplary user) is not likely to do. Not obvious at all.

According to that documentation, it's only been available since 4.3, so I've probably never actually tried it on 3.x, and I'm too lazy to hook up one of me legacy players at the moment, so I'll take your word for it Smiley Wink
My Channels: http://roku.permanence.com - Twitter: @TheEndlessDev
Instant Watch Browser (NetflixIWB), Aquarium Screensaver (AQUARIUM), Clever Clocks Screensaver (CLEVERCLOCKS), iTunes Podcasts (ITPC), My Channels (MYCHANNELS)
0 Kudos
dcrandall
Level 7

Re: bugs in roTextScreen component

Is there any way to transfer focus to the button when we load the page?

I ask because we often have miniscule amounts of text, but more so than an roParagraphScreen could display...and we have a 'back' button. We've run across where the user has to hit 'ok', and then 'ok' again to use that back button.

In theory they could just hit the back arrow, but having a 'back' button we find appealing.
0 Kudos