Hi Robert,
If I am running a process of 100 loops and my bar is 200 pixels,
then I want to update for each step. However, if my process runs
10000 loops, then updating for each step is pointless since the bar
will not visibly move and updating every 50-100 steps will do.
Maybe this is just a morning when I can't get it.
But unless your handler is hard-coded to the specific loop or makes
a runtime decision on whether to update every 50 steps, every 100
steps, or some number in between, I see no way the position of the
progress bar can accurately reflect the percentage of task
completion in all circumstances.
What I posted was generalized logic that calculates the number of
steps required to move the progress bar one pixel, regardless of the
width of the bar. That is the minimum steps required before
resetting the thumbPosition is visually manifested on the screen.
Anything more produces "jerkier" movements.
There is nothing wrong with your handler per se. I was trying to make
a general point and you are picking up on specific examples. Progress
is always a function of distinct steps in the process vs speed of
performing those steps vs visible effect of progression of the bar.
You can use a generic handler if you want to. I prefer to have more
customized handlers for each situation since I usually know what I
want to measure as progress. Actually, my database handling tasks
usually are complex enough that I use two-bar progress, one
progressing through main tasks and another progressing withing a
given task since each of those tasks has a different dynamic.
Robert
_______________________________________________
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
