Roku Developer Program

[renojim]

As I'm sure a lot of you do, I use the statement "msg = wait(0,port)" inside a while loop all over the place. I had assumed that the only way to get past that statement was to have a valid event for whatever component(s) port was associated with. I couldn't figure out why my code would crash on "print type(msg), msg.GetMessage()". After I split the print into two statements, I found out sometimes msg == invalid. That was something I did not expect and I suppose the validity of msg has to be checked every time. I wasn't bothering to check the type of msg if I was only using one type of component and a timeout of 0.

-JT

[greubel]

What type of object is port associated with ?

[renojim]

"greubel" wrote:
What type of object is port associated with ?

I'll have to double check, but I think it's associated with both an roImageCanvas and roVideoPlayer. It's something that I'm just using to test different things, so it's not like it's anywhere near being a finished channel. I was just printing out the messages as my loop received them and not acting on them. It may just be pressing the Home button that causes this - some sort of screwed up event dispatching while the channel is being killed. I guess if it's only the Home button that causes it then it may not be a big deal, but I still wasn't expecting it and it seems kind of sloppy if the Home button can cause strange events to be dispatched.

-JT

[kbenson]

I haven't experienced this, but I could see the home button causing something like this.

The home button used to send an event that could be caught as a message, but apparently some apps weren't the best behaved and they needed a way to ensure you could get to the home screen.

It's interesting if it is caused by the home button. If there's sufficient time before the app is actually killed, it's possible you could detect invalid events and use them to initiate some small cleanup routine, if quick enough. Of course, doing so would probably be using an undocumented "feature", frowned upon by Roku, and subject to stop working at any point if they changed the behavior.

[mainmanc]

If you receive an unknown event in your event loop, you should ignore it; then just continue processing other events. Roku may occasionally add new events, and if your event is written to exit on unknown events, any future events that Roku may add will cause your application to misbehave.

That is from the component reference guide. That may be what you are experiencing.

On a related note, I have been having some strange issues with the Home button and errors being thrown, but I will start another thread for that.

Cheers.

[kbenson]

"mainmanc" wrote:
On a related note, I have been having some strange issues with the Home button and errors being thrown, but I will start another thread for that.

My understanding is that there are currently *NO* guarantees about behavior, besides returning to the home screen, once the home button is pressed. I believe it was stated by a Roku employee that if you want to keep some sort of state, you need to save periodically. Other people have noted odd errors showing up when the home button is pressed, and that's probably to do with the application being uncleanly shut down (killed). I think the general consensus, or at least Roku's position, is to ignore these.

[mainmanc]

"kbenson" wrote:

"mainmanc" wrote:
On a related note, I have been having some strange issues with the Home button and errors being thrown, but I will start another thread for that.

My understanding is that there are currently *NO* guarantees about behavior, besides returning to the home screen, once the home button is pressed. I believe it was stated by a Roku employee that if you want to keep some sort of state, you need to save periodically. Other people have noted odd errors showing up when the home button is pressed, and that's probably to do with the application being uncleanly shut down (killed). I think the general consensus, or at least Roku's position, is to ignore these.

I am not having an issue with state, but it certainly is misleading when an error is thrown up on the console. As a programmer, that justs drives me nuts every time I see it 🙂 . If it is indeed a situation based on the "unexpected" return to the Home screen (which is appears to be) there should be at least some mechanism to either suppress or handle a clean return internally, instead just throwing an error, in my opinion.

Cheers.

[TheEndless]

"mainmanc" wrote:
I am not having an issue with state, but it certainly is misleading when an error is thrown up on the console. As a programmer, that justs drives me nuts every time I see it 🙂 . If it is indeed a situation based on the "unexpected" return to the Home screen (which is appears to be) there should be at least some mechanism to either suppress or handle a clean return internally, instead just throwing an error, in my opinion.

My guess would be that it's not actually returning and invalid msg, but instead killing the "wait" itself so msg is never set, in which case, it would be your code's responsibility to handle that situation, not the Roku.

[renojim]

I think the bottom line is that you have to test for msg being invalid after every wait. I was going under the assumption that the only way you could get an invalid message was if the timeout was something other than zero.

-JT

[mainmanc]

"TheEndless" wrote:

"mainmanc" wrote:
I am not having an issue with state, but it certainly is misleading when an error is thrown up on the console. As a programmer, that justs drives me nuts every time I see it 🙂 . If it is indeed a situation based on the "unexpected" return to the Home screen (which is appears to be) there should be at least some mechanism to either suppress or handle a clean return internally, instead just throwing an error, in my opinion.

My guess would be that it's not actually returning and invalid msg, but instead killing the "wait" itself so msg is never set, in which case, it would be your code's responsibility to handle that situation, not the Roku.

Yeah, that would make sense. What do you recommend as the best approach to handle those situations through code?

EDIT: Actually this looks more like the issue I'm talking about. http://forums.roku.com/viewtopic.php?f=34&t=28472&start=0