currentTime not being updated in standalone... arggghh!

[Josh Mellicker]

> 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
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your  
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution