I have a script that processes every record in a table. This can take anywhere from a few seconds to several minutes depending on the number of records and how much needs to be done on each one.

I'd like to give the users an indication of progress so (1) they can see something is happening and (2) predict the time to completion.

My first progress indicator was to refresh the form window as each record was processed. When there's little to do, the records change every 2-3 seconds. The users can roughly predict time to completion by watching the record counter in the left status area.

Occasionally it takes up to 20-30 seconds to process a single record. In this case, it appears the processing has hung. So I decided to show a progress indicator within each record.

Since my script knows the number processing steps for an individual record, I had the script update a simple progress bar field. Unfortunately, FileMaker doesn't display the changing field value while it's occupied with other processing.

Adding a "Refresh Window" each time the progress field changes turns out to be a performance killer because each Refresh takes 2-3 seconds - adding 20 - 60 seconds of Refresh overhead to each record. I tried replacing "Refresh Window" with "Pause/Resume Script" for 0.1 seconds, but the pause actually takes 1-2 seconds.

What I'd like is some way to trick FileMaker into quickly refreshing a single field each time the value changes.

Any suggestions?

Maybe the following thread will help

http://fmforums.com/forum/showtopic.php?tid/137110/post/186669/hl/progress/#186669

The separate Progress Bar window is an interesting approach.

However, my application is already displaying overall progress by displaying each record (with the record count in the status area). When there's minimal processing (the usual case), each record is displayed for only 1-2 seconds.

When a record needs serious processing, I'd like to show the progress in the record layout. My current design displays an indicator field (set to a vertical bar) next to each field as it is processed. In order to get the indicator to actually appear, I have to use Refresh Window. But, with 10-20 fields per record, the Refresh Window action adds 20-40 seconds per record -- way too much overhead, especially when the actual processing is only 1-2 seconds.

Why does a refresh take so long? Perhaps you need to switch to a simpler layout for this.

Why does a refresh take so long? Perhaps you need to switch to a simpler layout for this.

This prompted a closer look at the layout. I found it was displaying 6-12 full-size images in small container fields. Using the image thumbnails cut about a second off the refresh time.

Further investigation shows the processing performance is more than simply the Refresh Window time.

1. I wrote a simple script that does nothing more than 10 Refresh Window actions + reporting the elapsed time. The actual refresh time is only 0.4 seconds.

2. Adding a Freeze Window after each Refresh Window cuts the start-to-finish time in half!

The actual processing involves switching layouts, which happens so quickly the switch is invisible even without Freeze Window. It appears these layout changes is what's making Refresh Window take 1-2 seconds (instead of just 0.4 seconds).

I think a more meaningful test might be to perform the calculations while displaying a completely empty layout - shown as form, with Freeze Window and no refresh. That will give you the net time of calculations (which perhaps could be subject to optimization as well?). Anything on top of that is screen redraw time, and as such is a function of layout complexity, and little else.

A progress bar with a TEXT result - using Webdings font, for example - should redraw very quickly.