When showing progress, if you have a list of a known length and processing each item takes about the same time, you can implement this simply with code like this:

    for (int i = 0; i < list.Length; ++i) {
        Process(list[i]);
        NotifyProgress(i, list.Length); // takes a numerator and denominator for the % progress
    }

One common problem is not knowing the length beforehand. This happens when processing records from a database, and with DotImage, if you use some kinds of ImageSource objects (not surprisingly, ones connected to a database, but others as well).

A simple solution would be to pick a value for length and then make sure not to go over it.

    int lengthGuess = 100;
    for (int i=0; list.HasMoreItems(); ++i) {
        Process(list.NextItem());
        NotifyProgress(min(i, lengthGuess), lengthGuess);
    }
    NotifyProgress(lengthGuess, lengthGuess);

This works ok, if the length is near 100, but if it's much smaller, it will have to jump at the end, and if it's much bigger, it will get to 100% way too soon.

To fix this, we might adjust lengthGuess as we learn more:

    int lengthGuess = 100;
    for (int i=0; list.HasMoreItems(); ++i) {
        Process(list.NextItem());
        if (i > .8 * lengthGuess) {
            lengthGuess = 2*i;      
        }
        NotifyProgress(i, lengthGuess);
    }
    NotifyProgress(lengthGuess, lengthGuess);

In this last example, whenever i is 80% of the way through, we set lengthGuess to 2*i.  This has the effect that the progress goes back and forth between 50% and 80% and then it jumps to the end.  This won't work. 

What I want is:
  1. The progress bar should be monotonically increasing
  2. It should get to 100% at the end and not before
  3. It should look as smooth as possible, but can jump
An acceptable effect, would be to progress quickly to 50%, then slow down to 75% (50% of the way from 50% to 100%), then slow down again at 87.5% (halfway between 75% and 100%), and so on.  If we keep doing that, we'll never get to 100% in the loop and can jump to it at the end. This is like Zeno's Dichotomy paradox (from the Wikipedia).
Suppose Homer wants to catch a stationary bus. Before he can get there, he must get halfway there. Before he can get halfway there, he must get a quarter of the way there. Before traveling a quarter, he must travel one-eighth; before an eighth, one-sixteenth; and so on.

To do that we have to keep a factor to use to adjust the progress we've made (playing around with it, I found that using a factor of 1/3 rather than 1/2 was more pleasing).

    int lengthGuess = 100;
    double begin = 0;
    double end = lengthGuess;
    double iFactor = 1.0;
    double factorAdjust = 1.0/3.0;

    for (int i = 0; list.HasMoreItems(); ++i)
    {
        Process(list.NextItem());               
        double progress = begin + (i - begin) * iFactor;
        if (progress > begin + (end-begin) * factorAdjust)
        {                   
            begin = progress;
            iFactor *= factorAdjust;
        }               
        NotifyProgress(progress, lengthGuess);
    }
    NotifyProgress(lengthGuess, lengthGuess);

The choice of lengthGuess is important, I think erring on too small is your best bet.  You don't want it to be exact, because we'll slow down when we get 1/3 toward the goal (factorAdjust).  The variables lengthGuess and factorAdjust could be passed in and determined from what information you have about the length of the list.

 
UPDATE: More thoughts on Zeno's Paradox Progress Bars from Dave