What happens: you can conceivably end up with 100's of
updateTC sitting in the pending message queue... this actually
happened to me once and my application would slowly grind to a halt
with users complaining they could no longer even type in a field...
the CPU was so eaten up by processing the pending msgs queue.
Sivakatirswami, I WONDERED why typing in the notes field was so
slow!!! Thanks so much!!!
I added the check back in and typing is normal and the counter still
works in the standalone.
THANKS!!!
On Apr 28, 2006, at 3:00 AM, Sivakatirswami wrote:
Here is my incredibly verbose version of this:
on postTime
put empty into fld "thetime"
--put "Duration: " & fld "theTime" & cr into tFeedBack
put the timescale of player "theTape" into gTimeScale
--put "timeScale: " & intervalsPerSec & cr after
tFeedBack
put the currentTime of player "theTape" into fld "theMovieTime"
--put "Current Time: " & fld "theMovieTime" & cr after
tFeedBack
put the currentTime of player "theTape" into tCurrentTime
put (tCurrentTime div gTimeScale) & " secs" into fld "theTime"
if tCurrentTime is not (the duration of player "theTape") then
send postTime to me in 1 seconds
else
answer "Tape is over!" with "OK"
end if
end postTime
be very careful, since you have eliminated Eric's test:
IF ",updateTC," is not in the pendingMessages THEN send
"updateTC" to me in ((1 - (the long seconds mod 1)) / 5) seconds
that you are not issuing the "updateTC" somewhere, in some other
handlers on a loop that my be triggere by user actions like start
or stop the player etc. What happens: you can conceivably end up
with 100's of
updateTC sitting in the pending message queue... this actually
happened to me once and my application would slowly grind to a halt
with users complaining they could no longer even type in a field...
the CPU was so eaten up by processing the pending msgs queue.
I never thought of the test that Eric used but I'm going to add
that right away to my app!~
if ",postTime," is not in the pendingMesssages then
send postTime to me in 1 second
end if
Also be forewarned, I've found that on some windows systems, it
takes quite a bit of time, even after starting the player, before
the system is able to read any of the player time properties. This
has led to "support calls" from users where certain of my functions
that depend on the current time do not work in during the first
5-10 seconds of running time... I ended up putting the info on the
display and telling everyone that, until they start seeing time
being updated, not to touch those controls...
Sivakatirswami
On Apr 27, 2006, at 6:36 PM, Josh Mellicker wrote:
Never mind!
ON updateTC
put convertTime(round(the currentTime of player "Player"/the
timeScale of player "Player")) into fld "mt"
send "updateTC" to me in 50 milliseconds
END updateTC
did the trick.
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
