Roku Developer Program

[destruk]

When my app opens, I have it draw an roImageCanvas facade, followed by an rokeyboard screen (to force the overhang image to display), and then immediately draw a dialog box on top.
On my roku3 it works just fine - on a brand new never-been-used roku3 it appears to lock up at the rokeyboard screen and the dialog box never shows up - so it basically appears to crash with only 'home' as a valid choice.
Between the rokeyboardscreen.show command the the call to create the dialogbox in a separate function, there aren't any other instructions, so I'm at a loss why the keyboardscreen would show up but not the dialog box.
-- if you press home and re-enter the app then it works as it should - maybe due to some images or screens already being cached? or what?
So I added a sleep(125) between the two lines where it appears to fail and we will test with the sleep in there.

I have also noticed, sometimes, if I capture a string from rokeyboardscreen, and I don't immediately do a print of the captured result, roku forgets what the captured string was - like the function garbage collector is deleting the value before it can complete the return value to the calling line for the function. Some of these issues make me pull out a lot of my hair and makes me shudder to imagine what roku's underlying source code jumbled mess cobbled together with bubble gum looks like.
This loss of input also happens on the pin code entry screen type as well as some dialog boxes with lots of buttons. Much like how on the home menu of roku if you hit a button too fast it gets all confused now (at least on Roku2 XS). Just today I had My Channels highlighted and it was still showing the settings options on the right side of the screen. I was like WTF? Just what do you think you're doing anyway? 😉

[TheEndless]

I can't say I've seen any of these issues, but the call to .Show() is asynchronous, so it's possible the dialog is displaying faster than the keyboard screen, so it's there, but lower in the screen stack. If that's the case, then adding a Sleep() should work.

As for the keyboard losing the captured string, that sounds very odd. Can you explain what you mean by "captured string". Are you referring to the value in roKeyboardScreen.GetText()? Would you be able to provide a code snippet that exhibits the issue?

[destruk]

We're going to take a few days and test with the sleep in there for the first issue.
That's just it TheEndless - it'll work without the print statement 95% of the time or so, some roku's never exhibit the problem, but some do. So I end up always printing the result to cover all cases. 😞
The code is really basic IMO.

	m.text=EnterText()
	Print m.text
	If m.text="msg.isScreenClosed()" End

Function EnterText() As String
	textscreen=CreateObject("roKeyboardScreen")
	port=CreateObject("roMessagePort")
	textscreen.SetMessagePort(port)
	textscreen.SetDisplayText("Enter text")
	textscreen.SetMaxLength(100)
	textscreen.AddButton(1,"Finished")
	textscreen.AddButton(2,"Cancel")
	textscreen.Show()
		
	While TRUE
		msg=Wait(0,port)
		If Type(msg)="roKeyboardScreenEvent"
			If msg.isScreenClosed()
				Return "msg.isScreenClosed()"
			Else If msg.isButtonPressed()
				If msg.GetIndex()=1
					textentry=textscreen.GetText().Trim()
					Print textentry
					If len(textentry)>0 Exit While
				End If
				If msg.GetIndex()=2
					Return "msg.isScreenClosed()"
				End If
			End If
		End If
	End While
	Return textentry
End Function

Also sometime simply retrieving a value from the roku registry lags out, so the next instruction sees 'invalid' - so I need to print the result after each registry read too. As long as the prints are in place after each, it resolves fine.