Roku Developer Program

[MSGreg]

[Edited to reflect I don't think this is a bug, based on TheEndless' response below, and to change mentions of "roDetailScreen" to "roSpringboardScreen"]

The following subroutine demonstrates a bug I think that is different from this other one.

The bug here is when opening an roSpringboardScreenon top of a double-buffered roScreen. After closing the roSpringboardScreen, the code requires an extra sleep/swapbuffers in order to redraw the screen as expected.
A sleep of 1 does not work (on my Roku 2 XS), but a sleep of 10 does. I believe neither the sleep nor the extra SwapBuffers should be necessary.

' Demonstrates a bug in redrawing an roScreen after the call/closing of an roSpringboardScreencomponent.
' Test on a Roku 2 XS, Software version 4.8 - build 1178
Sub roScreenBugDemo()

	codes = bslUniversalControlEventCodes()
	
	rscreen=CreateObject("roScreen",true)
	msgport = CreateObject("roMessagePort")
	rscreen.SetPort(msgport)	

	while (true)
		' Draw a blue background, wait for OK button
		rscreen.Clear(&h0000FFFF)
		rscreen.SwapBuffers()

		while (true)
		msg=wait(0, msgport) ' wait for OK button
			if type(msg)="roUniversalControlEvent" then
				print "**** UniversalControl Event Int ";msg.GetInt()
				if msg.GetInt()=codes.BUTTON_SELECT_PRESSED then 'ok button pressed
					exit while
				end if
			end if
		end while

		' At this point, the OK button has been pressed
		' So let's create the springboard with two choices.
		' The user can select to exit the screenboard normally, or with the extra sleep/swapbuffers
		dscreen = CreateObject("roSpringboardScreen")
		dscreen.SetDescriptionStyle("generic")
		dscreen.SetPosterStyle("rounded-square-generic")
		dscreen.AddButton(0,"Ok")
		dscreen.AddButton(1,"With Extra SwapBuffers")
		dscreen.SetContent({Description:"Press OK, and you then can't move the button, (we'll be in the roScreen event loop). And if you press 'OK' again, then you'll see a 'new' detailscreen in which you can move the cursor."})
		port = CreateObject("roMessagePort")
		dscreen.SetMessagePort(port)
		dscreen.Show()
		
		while true
			extra = false
			msg = wait(0, port)
			if msg.isScreenClosed() then
				exit while
			else if msg.isButtonPressed()
				print "msg: "; msg.GetMessage(); "idx: "; msg.GetIndex()
				if (msg.GetIndex() = 0 )
					exit while
				else if (msg.GetIndex() = 1 )
					extra = true
					exit while
				end if
			endif
		end while
		dscreen.Close()
		if ( extra )
			' If this sleep/swapbuffers is NOT called, then the detailscreen remains visible
			' At that point, you can't move the button, and if you press "OK again, then you see a "new"
			' detailscreen in which you can move the cursor.

			' This error points to the clear/swapbuffers at the beginning of the event loop
			' are ineffective without these two statements:
			sleep(100) ' sleep(1) isn't apparently long enough for the Roku 2 XS
			rscreen.SwapBuffers() ' both the sleep and this extra SwapBuffers is required, I don't know why
			' Note that after this loops, the first thing we do is redraw and swapbuffers again.
		end if
	end while
End Sub

[TheEndless]

Technically, according to the documentation, what you're doing shouldn't be possible at all. Per the documentation:

"http wrote:
Once an roScreen is created, the display stack enters "Game Mode", and other screen components cannot be used. Other screen components cannot be intermixed with roScreens as the roScreen display stack is maintained independently from the main screen component display stack. When the final roScreen component is closed, other screen components can be used again.

Based on that, you shouldn't be able to display the details screen at all until you've destroyed the roScreen, which your code doesn't appear to be doing. "Game Mode" is probably what's causing the behavior you're seeing.

[MSGreg]

Thanks! Based on the documentation, I retract the categorization of this as a "bug".

You are correct that my code does not destroy the roScreen prior to showing the roDetailsScreen. Perhaps the way I'm trying to use this is an undocumented, unsupported feature. If even that.

I originally interpreted "Components" to be roImageCanvas. But on reading again, I think you're right.

Perhaps I'll rewrite to destroy the roScreen before creating the roSpringBoard.

I wonder if the restriction requires destroing roScreen before *CreateObject* roSpringBoard or before *Show()* roSpringBoard.

Thanks, TheEndless. It seems like you're my personal Roku Developer Guide. Your ** Valued Community Member ** is well earned. I appreciate it!

[destruk]

An roScreen.Close() command would be great to have - otherwise you destroy the roscreen by exiting the function/subroutine that created it - which means it could still be floating around in ram somewhere before the garbage collector kicks in.
Setting it to =nothing frees the reference, but I'd like to see some more definitive way of destroying the created component.

[MSGreg]

I was hoping that I could use an roScreen as a part of a menu stack of roParagraphScreens/roPosterScreens, and be able to place a roSpringBoardScreen occasionally on top for user interaction. In my use case, I would expect the roScreen to completely obscure what is under it and it would be completely obscured by what was on top of it. That way, you could choose roImageCanvas or roScreen as needed and still maintain a menu stack.

Based on the comment in the manual, this would not be officially supported. If there is another official stance, I'd love to hear it 🙂

[TheEndless]

"MSGreg" wrote:
I was hoping that I could use an roScreen as a part of a menu stack of roParagraphScreens/roPosterScreens, and be able to place a roSpringBoardScreen occasionally on top for user interaction. In my use case, I would expect the roScreen to completely obscure what is under it and it would be completely obscured by what was on top of it. That way, you could choose roImageCanvas or roScreen as needed and still maintain a menu stack.

Based on the comment in the manual, this would not be officially supported. If there is another official stance, I'd love to hear it 🙂

Presumably you still have references to all of the bitmaps and/or sprites you're drawing to the screen, so you should be able to just invalidate the roScreen immediately before showing the other UI screens, then recreate it as soon as the screens higher in the stack get closed. I'm 95% sure it's just the use of the video buffer that's in contention, so invalidating the screen should release it. For example,

screen = CreateObject("roScreen", True)
compositor = CreateObject("roCompositor")
compositor.SetDrawTo(screen, &H000000FF)
' bitmap and sprite creation and drawing
... event loop code ...
' event triggers the details screen
' invalidate the roScreen object to release the reference and buffer
screen = invalid

' draw your details screen and block
ShowDetailsScreen() 'blocks until closed

' details screen is closed, recreate roScreen
screen = CreateObject("roScreen", True)
' compositor is still in memory with all of its sprites intact, so
' we just need to reset its target to the new screen reference
' and redraw all of its sprites
compositor.SetDrawTo(screen)
compositor.DrawAll()
' repaint the screen
screen.SwapBuffers()