Rob Cozens wrote:
Hi Alex,
The other method would replace the last line with something like
if ticks()-lastTicks > 5 then
set thethumbPosition of scrollBar "Progress Scrollbar"
to recordsProcessed
put ticks() into lastTicks
end if
My logic says to me that handler cannot produce consistent results
across multiple progress bars--or even the same bar when the bar is
resized or the number of loops changes.
Given time, perhaps the light will dawn. Thanks for trying to educate
me.
You are partially right - the handler as it was wasn't quite good enough
....
I switched to Mac (which does do actual pixel-by-pixel progress bars)
and the time-based version was noticeably "chunky" in its updating. So I
thought some more about the math (let's see 60 ticks per sec divided by
30 frames per second = 2 ticks !!, not 5)
So I changed the time-based test to be " .... ticks() - lastTicks >
2 ..." and it looks good. And (on my Mac mini) it reduces the time
overhead of updating the display from 1.2 second (i.e. 60%) to around .2
second (11%) for the example we've been discussing (200 pixels, 1000
records, 2 seconds processing time)
You can try it out on a variety of scrollbar sizes, loop sizes and times
- download from RevOnline under username alextweedly called ProgressExample
(I'm not brave, or foolhardy, enough to have posted my last couple of
emails on this topic without trying it out first :-)
--
Alex Tweedly http://www.tweedly.net
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.385 / Virus Database: 268.4.0/305 - Release Date: 08/04/2006
_______________________________________________
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
