Delay after clicking search on search screen

Archived
1

In my app, I have several search screens. After entering a search phrase and clicking search there is about a 10 second delay before the system returns to the main poster screen. Is there something I can do to let the user know that something is happening after they hit search? The search screen keeps flashing the cursor, so it looks like nothing has happened. Also, would like to know any suggestions for forcing the main posterscreen to show “Retrieving” until the data actually shows up, there is a delay here as well where the Roku is retreiving images for the posteritems, and sometimes the posteritems themselves don’t show up right away.

Thanks,

  • Joel
2

Well, I’ve solved part of the problem by clearing the array of posteritems

posteritems.clear()

and then

poster.SetContentList(posteritems)

before I run the more time consuming parts of the app.

However, still need a way to make the search screen go away immediately after “Search” is clicked. Screen.close sends a screenclosed message which exits the function I’m in.

Any suggestions? Endless?

  • Joel
3

Are you using the SearchWindow code that I posted previously (viewtopic.php?f=34&t=32518&p=202516#p202518)?
It should close itself before returning the search screen for your processing. During processing, you can always show a roOneLineDialog with a “Please Wait…” message on it.

4

No, I’m not, mine works like this:

itemindex=msg.GetIndex()
if itemIndex = 0 then mainposter[m.li]=reloadTracks(mainposter[m.li],SearchTracks())

SearchTracks sets up the search screen and shows it, then calls the sub that gets the results, which are returned to Searchtracks and the result passed back up, where they are processed, played etc, so:

main()--------->SearchTracks()------>search window needs to close here---->GetSearchTracks(querystring)--------->Get Track

5

If you’re exiting your loop on a isScreenClosed() event, then you’ll need your search screen to use a different message port.

6

Ok, that worked!

I’m not sure why using a different message port made a difference, can you explain?

  • Joel
7

“jbrave” wrote:
Ok, that worked!

I’m not sure why using a different message port made a difference, can you explain?

  • Joel
    Because you have code that exits your wait loop when you receive an isScreenClosed event. If you’re using the same wait loop with the same message port for multiple screens, then you’re going to get the isScreenClosed event for the first one that closes and exit the loop. You should have separate wait loops for each screen, in which case you could share a message port.