Roku Developer Program

Join our online forum to talk to Roku developers and fellow channel creators. Ask questions, share tips with the community, and find helpful resources.
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
YoJae
Visitor

Re: roTextScreen and auto/manual focus on a button.


Actually, if you rearrange that a little more, you can avoid the flashing, too. This is how I typically do it:
    screen = CreateObject("roTextScreen")
screen.SetMessagePort(CreateObject("roMessagePort"))

' Add empty text initially
screen.SetText("")
' Add the buttons
screen.AddButton(0, "I agree")
screen.AddButton(1, "Cancel")
' Show the screen
screen.Show()
' At this point the buttons should have focus, so now add the real text
screen.AddText("Real text goes here")


This takes off the bottom scrollbar, thanks for your suggestion!
BUT
if you list the second button after show(), you couldn't be able to go up from it, it will jump to the text scrolling.
    
screen.AddButton(1, "Ok")
screen.show()
screen.SetText("Lorem ipsum dolor sit amet")
screen.AddButton(2, "Not ok")
0 Kudos
YoJae
Visitor

Re: roTextScreen and auto/manual focus on a button.

Awesome, thanks for this trick!
0 Kudos
YoJae
Visitor

Re: roTextScreen and auto/manual focus on a button.


Actually, if you rearrange that a little more, you can avoid the flashing, too. This is how I typically do it:
    screen = CreateObject("roTextScreen")
screen.SetMessagePort(CreateObject("roMessagePort"))

' Add empty text initially
screen.SetText("")
' Add the buttons
screen.AddButton(0, "I agree")
screen.AddButton(1, "Cancel")
' Show the screen
screen.Show()
' At this point the buttons should have focus, so now add the real text
screen.AddText("Real text goes here")


This takes off the bottom scroll-bar, thanks for this trick!
BUT
if you list the bottom button before show(), you couldn't be able to go to the top button, it will jump to the text scrolling instead.

 
screen.SetText("")
screen.AddButton(1, "Ok")
screen.show()
screen.AddText("Lorem ipsum dolor sit amet")
screen.AddButton(2, "Not ok")
0 Kudos
EnTerr
Roku Guru

Re: roTextScreen and auto/manual focus on a button.

"TheEndless" wrote:

Actually, if you rearrange that a little more, you can avoid the flashing, too. This is how I typically do it:
    ' Add empty text initially
screen.SetText("")
' Add the buttons
screen.AddButton(0, "I agree")
screen.AddButton(1, "Cancel")
' Show the screen
screen.Show()
' At this point the buttons should have focus, so now add the real text
screen.AddText("Real text goes here")

Seems like a volatile dependency - not only does it depend on focus not auto-changing on modification (reasonable) but also on faith that empty text field will be un-focusable (implementation behavior). Such solution warrants a "FDA boxed warning" on the bottle 🙂
0 Kudos
YoJae
Visitor

Re: roTextScreen and auto/manual focus on a button.

OK guys, this solution eliminates flickering in 85% of times


screen.AddButton(1, "Ok")
screen.show()
canvas = CreateObject("roImageCanvas")
canvas.Show()
screen.AddText("Text")
canvas.close()
screen.AddButton(2, "Cancel")
0 Kudos
TheEndless
Channel Surfer

Re: roTextScreen and auto/manual focus on a button.

"EnTerr" wrote:
Seems like a volatile dependency - not only does it depend on focus not auto-changing on modification (reasonable) but also on faith that empty text field will be un-focusable (implementation behavior). Such solution warrants a "FDA boxed warning" on the bottle 🙂

Care to explain what you mean by volatile? There's absolutely nothing in that code that is not supported by the documentation, nor does it require a hack like showing an image canvas for no reason. You can add text to a text screen at any time, so there's nothing dangerous about doing it in the order my code does. Absolute worst case, the buttons don't have focus initially, but that's the issue we're trying to work around. In my testing, and I've done this in multiple channels, this works 100% of the time.

Ideally, Roku should give us the ability to set focus on the buttons, but in lieu of that everything is "volatile" in the sense I think you're using it...
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
Roku Guru

Re: roTextScreen and auto/manual focus on a button.

"TheEndless" wrote:
Care to explain what you mean by volatile? There's absolutely nothing in that code that is not supported by the documentation, nor does it require a hack like showing an image canvas for no reason. You can add text to a text screen at any time, so there's nothing dangerous about doing it in the order my code does. Absolute worst case, the buttons don't have focus initially, but that's the issue we're trying to work around. In my testing, and I've done this in multiple channels, this works 100% of the time.

Ideally, Roku should give us the ability to set focus on the buttons, but in lieu of that everything is "volatile" in the sense I think you're using it...

Sorry, i used a lingo from a "dependency injection" metaphysic talk i attended the previous day. They talked about the judgement call one has to make in deciding which code dependencies are "stable" vs "volatile". Because at first they tell you using "new" in your component for external component is a "code smell" and instead you should be injecting these from outside and let caller handle their lifetime. But if one starts practicing that religiously, therein lies a shortcut to insanity (someone has to create all objects after all - incl. String/StringBuilder- and main() can't do them all). And so they tell you need the wisdom to predict which dependencies are stable and most unlikely to change vs volatile ones that are worth injecting.

In the same way i thought, some of the unspecified/undocumented behavior here is more likely to change than other. For example, making judgement calls (if i understood what your code relies on) - default focus being on the first enabled control = not likely to change; empty text field being disabled though (and hence skip focus on show()) seems to me a volatile expectation.

So my point was "volatility" is a continuous scale, some shades of gray are darker and hence the "warning label" - just like with drugs, it's not a ban but "use yet mind the risks". With that sticker on the side, i think your code is a great hack that does the job.

Fixing the component - sure thing, if you see earlier in the thread i was calling for fixes (like focus and custom font size).
0 Kudos