Is there a way to manually send focus to a button?
I ask because our application has these roTextScreens, and the desire was to have an illustrated ‘back’ button. To get the back button to work, one has to get the focus in that direction. It usually takes one button press to remove the focus from the roTextScreen scroll area to the buttons, and another key press to activate the button.
So we pull-up our ‘roTextScreen’ and we have to go ‘click click’ on the ok button to go back.
I know the back button is there, and it works, but it’s the way we use it…so it’s the way we think our customers will.
Sorry, there is no secret method for setting the button focus.
Better approach would be to create your own custom screen and not use the roTextScreen, that screen type was created for one purpose, which was to display and accept a click-through agreement on the firmware 4.9 home screen. It isn’t really suited for any other purpose.
OP, you could send an OK click via ECP once the screen is drawn to force a focus change.
Thank you, this works!
Here’s my fix if anyone needs it.
fnSimulateKeyPressECP("Select")
function fnSimulateKeyPressECP(keypress as string) as void
url = "http://127.0.0.1:8060/keypress/" + keypress
request = CreateObject("roUrlTransfer")
port = CreateObject("roMessagePort")
request.SetMessagePort(port)
request.SetUrl(url)
request.PostFromString("")
end function
This won’t work with 1st gen players (fw3), if i remember - loopback interface is blocked, have to find the external IP instead. And that makes me uneasy since that may get axed: usually it’s the other way around - host firewall will block loopbacks on external interface but allows that on 127.0.0.1
Joel - can’t you just put a word on roTextScreen to be fixed up a bit? viewtopic.php?f=34&t=65885
To me it seems like a fixer-upper (and then we can start flipping it )
I hate to ask, but I have to ask… say my little ECP hack gets blocked in the future with the loopback like that, is it going to be like, blow-up bad, or just sad-trombone bad?
Because as it’s used, if it doesn’t work, it’s just sad-trombone bad.
Feature request - Could I find out if the text scrolls in roTextScreen? Like, if there’s 2 lines of text, there’s no scrolling. If there’s 400 lines of text, there’s gonna be some scrollin’. Without guessing by newlines and character counts, I can’t know.
“RokuJoel” wrote:
In the future the way the ECP works might change, with that in mind, I try to avoid recommending outside the box hacks like that.
I was actually referring to your dismissal of using the roTextScreen for anything other than license agreements as being inside the box. My ECP suggestion is definitely a hack.. no question about that.
“dcrandall” wrote:
I hate to ask, but I have to ask… say my little ECP hack gets blocked in the future with the loopback like that, is it going to be like, blow-up bad, or just sad-trombone bad?
Since it’s just a web request, it should only be sad-trombone bad. You might be safer grabbing the device’s IP (via roDeviceInfo) instead of using the loopback address, though, as I’d bet that much less likely to change.
“dcrandall” wrote:
Feature request - Could I find out if the text scrolls in roTextScreen? Like, if there’s 2 lines of text, there’s no scrolling. If there’s 400 lines of text, there’s gonna be some scrollin’. Without guessing by newlines and character counts, I can’t know.
Hehe.. there’s no built-in method of setting focus on the buttons, what makes you think there’d be a way to determine if it’s scrollable? Nope, making an educated guess based on content length is probably your best bet.
“TheEndless” wrote:
Hehe.. there’s no built-in method of setting focus on the buttons, what makes you think there’d be a way to determine if it’s scrollable? Nope, making an educated guess based on content length is probably your best bet.
So, there is no hope of customizing the font size, as to actually make the text readable in a 10-foot experience, huh?
I understand lawyers need of using fine print as small as possible (so nobody can actually read it) - but roTextScreen is almost finished and ready for use to show long texts - almost.
“dcrandall” wrote:
The only one I could suggest for the ‘.show()’ is send a down-arrow press 37 times to scroll to the end?
Care to imagine the sound of 37 clicks? :mrgreen:
Apologies for the late response! Thanks for the reply.
I’ve been knee deep in self pity as I’ve been trying to roll my own textScreen.
Now that I have something mostly* working, I can say that, I’ve been humbled. Greatly.
peace & 42
mostly (adverb): for the greatest part : mainly.
… as in, I still have text that can exit the box! ( parsing issue. data used elsewhere. )
… and I haven’t even started looking into making it SD resolution functional
… and no vertical scroll-bar / visible clue as to where in the text we’re at
… and NO awesome click sound effects! OH THE HUMANITY. ( honestly I like 'em… mostly )
If you draw to a region then draw the region to the screen, it should automatically clip any overflow.
Thanks for the tip, but I’m sorta in a paradox on this one. I haven’t yet proven that anything greater than 80 chars is clip-able or for that matter necessary to show at all. Granted having it go outside my textbox and out the side of the screen isn’t a solution. I just haven’t decided if I’ll manually insert a CR, LF, CRLR ( or is it LFCR? ) If I do that, then I have to count the lines being shown in the textbox differently or create a backup copy of the original data and not skip lines when moving up and down, when the wrapped lines scroll off the screen. I’m not converting the whole data and formatting it for my textbox control. I’m culling the lines I don’t need and sending off the shortened roList. Decisions. decisions.
FWIW, since the data is a roList of strings, I’d just take the first 80 chars that way.
If you just define the roScreen as 1280x720 and pretend there is no SDTV mode, the hardware will take care of it for you.
Is that enough to pass certification?
Similarly, how often are we allowed to update our app after it is published?
… and no vertical scroll-bar / visible clue as to where in the text we’re at
That should not be too difficult to do
Oh, but my talent lies in making things difficult!
Knowing what line I’m on and how many lines there are gives a percentage and via that we can drawRect() where it needs to be… just need a little more functionality as the data is not static. IOW, the size of the scroll bar widget thing.
Again, I agree, not too difficult. Just dealing with prioritizing tasks. First looking into changing the resolution to 1280x720 and see what falls off the screen and then change all objects to use relative screen positioning ( just in case the screen resolution needs to be changed in the future ). Also, the same method is being called for both my textbox control and my menu control… but doable. Totally doable.
take a look at roAudioResource. Sound effects are pretty easy, limitations are you need to use very small 16bit .wav files for your effects.
Yes, thank you. I’ve been using the Snake SDK example for some insights.
Or you know… alternatively RokuCo may just fix roTextScreen so we don’t have to re-invent the wheel. Somebody has already spent the time to do the scroll and bounding etc. 90%+ of the work was done, just fix few bugs and add font size.
Am i too extreme?
I see it as law of conservation of effort. Laziness - the first of the three great virtues of a programmer.
There is a simpler trick. You first set up top button, then show() the screen, then add text and then other buttons. Testes on Roku v6.02. When you start the screen the text blinks once, but this is much better then be out of focus.
screen.AddButton(1, "Ok")
screen.show()
screen.SetText("Lorem ipsum dolor sit amet")
screen.AddButton(2, "Not ok")
“YoJae” wrote:
There is a simpler trick. You first set up top button, then show() the screen, then add text and then other buttons. Testes on Roku v6.02. When you start the screen the text blinks once, but this is much better then be out of focus.
screen.AddButton(1, "Ok")
screen.show()
screen.SetText("Lorem ipsum dolor sit amet")
screen.AddButton(2, "Not ok")
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")
)
Nope, making an educated guess based on content length is probably your best bet.
