Roku Developer Program

[TheEndless]

My app seems to completely lose focus when the screensaver comes on, and doesn't get it back when the screensaver is closed. Is there something I need to be doing in my code to recapture focus? I have an roImageCanvas displayed when the screensaver comes on, if that matters at all.

Thanks in advance...

[RokuKevin]

You do not need to do anything special in your main thread to regain the focus.

Your RunScreenSaver() method should be sure to your event loop (and therefore RunScreenSaver() method) is exiting on a msg.isScreenClosed() event.

--Kevin

[TheEndless]

"RokuKevin" wrote:
You do not need to do anything special in your main thread to regain the focus.

Your RunScreenSaver() method should be sure to your event loop (and therefore RunScreenSaver() method) is exiting on a msg.isScreenClosed() event.

--Kevin

I have code in there to handle the isScreenClosed() event, but I never receive it. Interestingly, the Clock SDK app actually has a typo at that point in the code (looks for "roImageCanvas" instead of "roImageCanvasEvent"), so it never gets to that point either. My app doesn't receive focus after the screensaver whether I use a custom screensaver or the default screensaver, so it's not specific to my RunScreenSaver() code.

Unfortunately, since the screensaver runs in a separate thread, I can't attach to it in the debugger to see what events I do receive, either. Is there some way to debug a screensaver, aside from explicitly calling RunScreenSaver() from the main thread?

[renojim]

It sure would be nice to see debug output from screensavers. What I have done is to use the PostFromString function to post messages back to my server which then appends them to a debug.txt file.

-JT

[RokuKevin]

A good technique for debugging your screensaver code is to run the functions in the main GUI thread:

' Main() is useful for testing. It should be commented out before publishing app
Sub Main()
    Init()
    facade = CreateObject("roParagraphScreen")
    facade.Show()
    RunScreenSaverSettings()
    RunScreenSaver()
    facade.showMessage("")
    sleep(25)
End Sub

You can also check for print message statements on the RunScreenSaver() thread by telneting to port 8087

--Kevin

[TheEndless]

"RokuKevin" wrote:
A good technique for debugging your screensaver code is to run the functions in the main GUI thread:

While that's certainly useful for initial debugging, it doesn't take into account any global m. variables that may not be available to the screensaver thread, that are easily overlooked ( :oops: ) in private screensavers without a stack trace.

"RokuKevin" wrote:
You can also check for print message statements on the RunScreenSaver() thread by telneting to port 8087

This is great information! Is that documented somewhere? Are there any other ports that might be useful?

[RokuKevin]

Global m. variables can be accessed via the screensaver threads. Take care, there are no synchronization mechanisms!

[TheEndless]

"RokuKevin" wrote:
Global m. variables can be accessed via the screensaver threads. Take care, there are no synchronization mechanisms!

I'm not seeing this behavior. I've got a number of global m. variables in my main application that are not visible to the private screensaver I've got in the same application. I get "invalid" when I attempt to print the value to the console.

Are you saying that the application should be able to share global m. variables with the screensaver, or are you just saying that the screensaver can have it's own global m. variables? I'm guessing based on your synchronization warning, that you're suggesting the former, but I'm not seeing that.

On a related note, is there any way to set the screensaver to something less than 5 minutes? It's kind of a pain to have to wait for 5 minutes between screensaver tests. I know you can preview it through the settings menu, but my screensaver is using data from my running app, so the preview option doesn't really help me.

Thanks for your help!

EDIT: I just found out that port 8087 does actually show stack traces, so that's cool!

[RokuKevin]

TheEndless,

You are correct that m. variables are not shared in the RunScreenSaver() thread.... In order to avoid the synchronization problems I alluded to previously (and to be sure to cleanup resources) we made a decision to create a new global scope every time the RunScreenSaver thread is run. So, if you want to share data your only options are the registry and files.

--Kevin

[TheEndless]

"RokuKevin" wrote:
TheEndless,

You are correct that m. variables are not shared in the RunScreenSaver() thread.... In order to avoid the synchronization problems I alluded to previously (and to be sure to cleanup resources) we made a decision to create a new global scope every time the RunScreenSaver thread is run. So, if you want to share data your only options are the registry and files.

--Kevin

That's actually the route I went, so it's good to know I wasn't way off base.

Interestingly, to address my own problem in the first post of this thread, it turned out the focus problem I was having was due to a roOneLineDialog that was left running in the background (behind my roImageCanvas). It seems, if a dialog is displayed at any level in the screen stack, it gets the focus when returning from a screensaver. It was an easy enough fix, but you might want to consider looking into whether that should happen or not. I posted another thread on other roOneLineDialog behavior anomalies over here, if you care to comment: viewtopic.php?f=34&t=31028