Roku Developer Program

[renojim]

"TheEndless" wrote:

"MazeWizzard" wrote:
I still don't know what Wait() is doing for those 10-15 ms

My guess would be that it's doing a GetMessage() loop with a 1ms sleep. That would explain why a Wait(1) and a Sleep(1) produce the same ~10ms delay.

Doesn't Wait() with a non-zero timeout return immediately (give or take) if there's an event pending? That would imply it's not simply doing a Sleep().

-JT

[TheEndless]

"renojim" wrote:

"TheEndless" wrote:

"MazeWizzard" wrote:
I still don't know what Wait() is doing for those 10-15 ms

My guess would be that it's doing a GetMessage() loop with a 1ms sleep. That would explain why a Wait(1) and a Sleep(1) produce the same ~10ms delay.

Doesn't Wait() with a non-zero timeout return immediately (give or take) if there's an event pending? That would imply it's not simply doing a Sleep().

-JT

I'm not sure I follow...? The first parameter for Wait is the timeout in milliseconds, so my guess it is looks something like this:

Function Wait(timeout As Integer, port As Object) As Object
    If timeout = 0 Then
        Return port.GetMessage()
    Else
        timer = CreateObject("roTimespan")
        timer.Mark()
        While timer.TotalMilliseconds() < timeout
            msg = port.GetMessage()
            If msg <> invalid Then
                Return msg
            End If
            Sleep(1)
        End While
    End If
    Return invalid
End Function

[EnTerr]

"TheEndless" wrote:
I'm not sure I follow...? The first parameter for Wait is the timeout in milliseconds, so my guess it is looks something like this:

Seeing there is method WaitMessage(), it's probably more like:

Function Wait(timeout As Integer, port As Object) As Object
    If timeout = 0 Then
        Return port.GetMessage()
    Else
        return port.WaitMessage(timeout)
    End If
End Function

Or if WaitMessage has the same strange behavior to wait forever on timeout=0, then just Wait(timeout, port) == port.WaitMessage(timeout)

I have a question though - why is it that examples have code like

while True
  msg = wait(0, port)
  if msg <> invalid then
     ....
  endif

- Why does this code check if event is invalid, when it is known that it waits (forever) till a real event comes?!

[belltown]

"EnTerr" wrote:

I have a question though - why is it that examples have code like

while True
  msg = wait(0, port)
  if msg <> invalid then
     ....
  endif

- Why does this code check if event is invalid, when it is known that it waits (forever) till a real event comes?!

I think it's because even in a wait forever loop there are circumstances when an Invalid event may be received, which would normally be considered a timout if a wait time of >0 was specified. For example, pressing the 'Home' key causes a slew of Invalid messages. There's a discussion about that here: http://forums.roku.com/viewtopic.php?f=34&t=31487&hilit=wait+invalid#p193585

[EnTerr]

"belltown" wrote:

"EnTerr" wrote:
Why does this code check if event is invalid, when it is known that it waits (forever) till a real event comes?!

I think it's because even in a wait forever loop there are circumstances when an Invalid event may be received, which would normally be considered a timout if a wait time of >0 was specified. For example, pressing the 'Home' key causes a slew of Invalid messages. There's a discussion about that here: http://forums.roku.com/viewtopic.php?f=34&t=31487&hilit=wait+invalid#p193585

Thanks!
I found in examples reference to another case: debugger - and i am able to reproduce invalid as event after resume from ctrl-C. In this case I imagine returning null was just quick&dirty way to fix interruption of wait() and as far as i am concerned belongs to the set of bugs and not features. 🙂

[renojim]

And pressing the Home button on the remote will spew invalid messages, so it's best to always check for invalid even though your app is ending in the case of the Home button. Those unexpected invalid messages can still cause a crash in your app just before it's killed.

-JT

[renojim]

"TheEndless" wrote:
I'm not sure I follow...? The first parameter for Wait is the timeout in milliseconds, so my guess it is looks something like this: (clipped)

Ah, I see what you're saying. I thought you meant there was an inherent Sleep(timeout) to go along with the Wait(timeout,port). You could be right about a Sleep(1) in a loop.

I think the interesting part of this discussion is the undocumented port.GetMessage() function. I wonder how many other really useful undocumented functions there are.

-JT

[EnTerr]

"renojim" wrote:
I think the interesting part of this discussion is the undocumented port.GetMessage() function. I wonder how many other really useful undocumented functions there are.

It's documented - pg.90 of component reference,

roMessagePort GetMessage (Void)
roMessagePort WaitMessage(Integer timeout)

- with a note "When using BrightScript, you would not call these functions directly. Instead, use the “Wait” BrightScript statement"

Hmmmm... is it just me, or is this interface wrong? Those two methods do not return "roMessagePort", they return "roMessage***Event"

By the way, here on few occasions we talk about "invalid event", "invalid message" - that's not the case, you don't receive event that is invalid, you receive object "invalid" of type "Invalid" (which in other languages will be NIL, NULL or None), which is not message/event. Minor difference, the semantic being it is not some message we don't recognize but indicator there is no event (and in the case of break/Home, likely sloppy programming).

[renojim]

"EnTerr" wrote:
It's documented - pg.90 of component reference,

Weird... I searched for it and didn't find it. I wonder what I was searching. :?

"EnTerr" wrote:
Hmmmm... is it just me, or is this interface wrong? Those two methods do not return "roMessagePort", they return "roMessage***Event"

Gotta agree.

-JT