"TheEndless" wrote:
"RokuJoel" wrote:
Rather than using sleep to control event timing, as sleep() and wait() suffer from the same issue, consider using several roTimeSpan objects to trigger events at a specific duration
Assuming you mean inside a while loop (can't think of any other way to track it), without a sleep in there, that sounds like a really good way to lock up the box, particularly if you're not listening for any events. But, if you add wait in there to catch any events (and to give the processor some breathing room), you're right back to square one.
That's how I was thinking about it when I created this post. However, now I'm guessing that Wait() doesn't really do anything (as far as the message is concerned) other than wait on a message coming in.
So ... to rephrase... you don't need wait() to let the box process messages. You can just check the port directly without calling wait(). That processes the message, no waiting required.
As to using roTimeSpan objects... I use em for all sorts of stuff and even have a finite-state-maching pseudo-BG process. I don't use sleep() inside render loops either (or anywhere else other than in the code profiler calibaration routine...but that's changing too). But hey, it's an interesting discussion. A Sleep() routine is easy to create yourself if you want one. Joel is correct that you may as well do something while waiting.
The gang at Roku should verify what Wait() is doing...and if using it is somehow required once in a while. However...
while <looping-condition>
msg = msgport.GetMessage()
if type(msg) = ......
<process message>
end if
<other loop stuffis>
end while
Is a no-wait no-lockup way to do it, or seems to be so far. Like KevinG said above.
So... Kevin and Joel are correct that Wait() and Sleep() are probably, umm..., less than necessary. (EDIT: They didn't actually say that.. I don't want to mis-quote...so read above...looks like we have options). However the sample code is full of wait() s. lol.
I could always replace them for now with something like this (
I haven't checked this code at all ... just trying to communicate an idea here)
Function MyWait(ms as Integer, ThePort as Object) as Object
t = CreateObject("roTimeSpan")
result = ThePort.GetMessage()
while ms >= 0 and result = invalid and (t.TotalMilliseconds() < ms or ms = 0)
result = ThePort.GetMessage()
end while
return result
End Function
Sub MySleep(ms as Integer)
t = CreateObject("roTimeSpan")
while t.TotalMilliseconds() < ms and ms > 0
end while
End Sub
However, the question remains... why even use Wait() or sleep()? There may be a reason... but I don't know what it is (since I don't have their code... can't see the internals). Maybe it does give the processor a break... or give the IR/RF sensors time. Or something else entirely. I guess the question becomes... What do we lose? What's it doing now that it won't do if we omit Wait()?