Closing a roScreen

Invalidating the screen should close it...

screen = CreateObject("roScreen") ' Create the screen
' Do other stuff to draw on the screen
screen = invalid ' Close

"TheEndless" wrote:
Invalidating the screen should close it...

This is clever "evil hack" and usually it will do the job. However Roku should consider the lack of close() a bug and fix it.

Why evil hack - it relies on BS memory management deleting object immediately when reference count reaches 0. And that won't always work

screen = CreateObject("roScreen") ' Create the screen
' Do other stuff to draw on the screen
scr2 = screen
screen = invalid  ' Close
' nope, did not work because scr2 still points to the screen; scr2 has to be flushed too
' but wait, there is more!
aa = {scr: screen2}
scr2 = invalid 
' did not work again because aa indirectly points to it
aa.loop = aa
'let's expunge aa
aa = invalid
' ha, what is this? the screen is still there!

Well yeah, because there is cyclic reference the reference count of the assoc.array will stay 1 and not get freed, and so does roScreen stay in limbo with it.

"EnTerr" wrote:

"TheEndless" wrote:
Invalidating the screen should close it...

This is clever "evil hack" and usually it will do the job. However Roku should consider the lack of close() a bug and fix it.

Why evil hack - it relies on BS memory management deleting object immediately when reference count reaches 0. And that won't always work

screen = CreateObject("roScreen") ' Create the screen
' Do other stuff to draw on the screen
scr2 = screen
screen = invalid  ' Close
' nope, did not work because scr2 still points to the screen; scr2 has to be flushed too
' but wait, there is more!
aa = {scr: screen2}
scr2 = invalid 
' did not work again because aa indirectly points to it
aa.loop = aa
'let's expunge aa
aa = invalid
' ha, what is this? the screen is still there!

Well yeah, because there is cyclic reference the reference count of the assoc.array will stay 1 and not get freed, and so does roScreen stay in limbo with it.

Good catch. I would have expected invalidating the base reference (screen in your example) to invalidate all references to it as well (i.e., scr2 should reference screen, so invalidating screen should derefrence scr2 as well, and up the chain). Curious... I wonder if explicitly calling RunGarbageCollector() would clear all of the references immediately.

Sometimes, vaguely, the environment reminds me of programming on a system with an event-driven terminal screen (real old stuff like CICS or something). I guess I think of the roScreen, and the sub that it's in, as an entity. The analogy is a bit strained since the event model is different, but I still think of them as a group.

Thus, when the sub ends, the roScreen goes out of context. Of course, if you set it to invalid "manually", you'd want to clean up any variable references before setting screen to invalid. Thus

scr2 = invalid
screen = invalid

is what you should do (assuming that scr2 would even stick around, or the program execution would stay in the current subroutine). I would structure my program around the design of the screen flow anyway.

sub main()
    DoParagraphScreen()
end sub

sub DoParagraphScreen()
...
   DoRoScreenFoo()
...
end sub

sub DoRoScreenFoo()
...
   screen =  ....
   if screen <> invalid then g.sc2 = screen
...
   g.sc2 = invalid 
end sub

So it's as much a design/program structure issue as it is any lack of close() functionality for the object.

Your point is well made tho. Invalidating an object and closing it are not necessarily the same thing logically. When it goes out of context with a reference count of zero, it must close by definition. However, you may wish to close it before it goes out of context.

The tricky part is ... if you called a screen.close() routine... now what does screen look like after the call returns? Is it invalid, or is it still pointing to a (now closed) roScreen that returns invalid for all calls? Essentially, the .Close() routine should be a destructor, and B.Script doesn't really have those. The usual way to destroy a variable is to let it's reference count go to zero when it goes out of context assuming you cleaned up all references nicely like you should. Interestingly, B.Script does force you to clean up your doubly linked variable references and play nice. Don't be sloppy with them. 😉

I had some code I was playing with where I would literally have a couple of hundred doubly linked variables. This was due to having a call-back function reference stashed in the objects (for speed). Now, of course, the garbage collector complained profusely in the debugger if I exited improperly. However, I cleaned up the references before destroying the objects, so that by the time I exited normally, there were no complaints. You have to be neat about it.