bugs in roTextScreen component

Archived
1

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:

    [upload|7DhrJ87npKkkYEFDYkjd3g==]

2

“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

3

“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.

4

“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).
5

“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.

6

“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 :wink:

7

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.