Revolution is very slow to refresh fields. How can I speed it up?

[Robert Brenstein]

>
>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