摘要
使用进度条监视器并不像看起来的那么简单，在使用时很容易犯错。这取决于各种因素，像底层实现，显示方式，是否被设定固定数目的工作条目，是否使用了SubProgressMonitor 嵌套，等等。结果可能是完全没问题，也可能是 让人挠头，或者彻底不可用。
本文将指导怎样有效的使用进度条监视器。
使用进度条监视器
在许多简单的惯例中，有一条是“只知道所知道的，并且仅限于此”。这就是说，不能假设完全了解你所不知道的事情。就像，你不能想当然的认为进度条监视器就是你在IDE中看到的那些图片样子的东西。IProgressMonitor
通常，所有的进度条操作都是通过IProgressMonitor接口.进度条监视器具有4中状态，通过接口只可以测到一种状态（当监视器被取消时）。状态的改变是通过如下方法的作用： beginTask(), done() and setCanceled(). - PRISTINE
IProgressMonitor实例被初始化之后，方法beginTask() 被调用之前的状态。 - IN_USE
方法beginTask()被调用之后的状态，这里要注意 beginTask()只能被调用一次， - FINISHED
done()被调用之后的状态， 它也只能调用一次，并且只能在 beginTask()之后调用。 - CANCELED
进度条被取消之后的状态。
要以以下的模式使用进度条:
monitor = ? // 获取进度条实例，现在处于 pristine 状态
try
{
monitor.beginTask(?
// 执行工作任务
}
finally
{
monitor.done()
}
The 一定到保证 done() 最后被执行。子任务用代理使用进度条监视器
beginTask()被调用不要多于一次，这种错误经常发生。进度条被传给子任务，子任务没有意识到进度条已经执行了beginTask()，还是按照规定的契约，执行beginTask()方法。除非子任务对此了解，否则传递进度条实例是十分错误的。一般情况下，接受到进度条实例的代码应该假设此实例自己会遵守beginTask()/done()契约。如果子任务也需要进度条，就应该使用SubProgressMonitor作为代理，封装传入的进度条实例。
如下为样例:
monitor = ?// 获取进度条实例
try
{
monitor.beginTask(?
// 执行任务
?BR>// 创建一个子任务
someThing.doWork(new SubProgressMonitor(monitor,?)
// // 创建右一个子任务
anotherThing.doWork(new SubProgressMonitor(monitor,?)
}
finally
{
monitor.done()
}
管理条目个数
如果确实不知道确切的条目总数，不要随意猜测数字。如果猜大了，数字会走的很慢，然后突然到达100%；如果猜小了，那么会很快到达终点，并且永远停在那里。没有确切总数的话，填写 IProgressMonitor.UNKNOWN就可以了。怎样调用 beginTask() 和worked()
通常你可以通过两种方式得出你究竟要处理多少条目：一是调用许多不同的方法来得到结果，二是在一个集合中为每一个实例调用同一个方法。每种方式你都可以知道总的条目数（方法的个数或集合的大小）。
你应该将按比例测量出你的总数。如果总数是3 (每个条目工作为worked(1))，你可以把比例定为1000，总数为3000， (每个条目工作为worked(1000) ). 当你要通过SubProgressMonitor将工作传递到子任务中，就要应用这种方式。因为子任务内部的总数和外部是不同的，也许比你定的总数大许多。你要给它们一些缓冲润滑的空间。这样可以避免进度条执行时视觉上的便扭。
样例:
monitor = ?// 取到进度条监视器
int total = 3 // 总数为3
try
{
monitor.beginTask(total)
// 条目1
this.doPart1()
monitor.worked(1)
// 条目 2
this.doPart2()
monitor.worked(1)
// 条目 3
this.doPart3()
monitor.worked(1)
}
finally
{
monitor.done()
}
这里没有必要按比例放大，也没有集合动态计算。
更详细的样例:
monitor = ?
int total = thingyList.size() * 3 + 2
try
{
monitor.beginTask(total)
// 条目 1
this.doBeforeAllThingies()
monitor.worked(1)
// 条目 2 to 倒数第二个
for (Thingy t : thingyList)
{
t.doThisFirst()
monitor.worked(1)
t.thenDoThat()
monitor.worked(1)
t.lastlyDoThis()
monitor.worked(1)
}
// 最后一条
this.doAfterAllThingies()
monitor.worked(1)
}
finally
{
monitor.done()
}
混合使用子任务
在使用子任务的时候，子任务的总数就是分配给它的比例数。
monitor = ?
int scale = 1000
int total = 3
try
{
monitor.beginTask(total * scale)
// item 1
this.doPart1()
monitor.worked(1 * scale)
// item 2
this.doPart2(new SubProgressMonitor(monitor, 1 * scale)) //分配一个条目
monitor.worked(1 * scale) // 这里是不需要的，因为任务的管理有子任务负责
// 条目 3
this.doPart3()
monitor.worked(1 * scale)
}
finally
{
monitor.done()
}
You worked().
不要将 IProgressMonitor.UNKNOWN 传给创建的 SubProgressMonitor()
子任务进度条的实现只是盲目的使用传入的总数进行计算，当它接受到的是一个负值(IProgressMonitor.UNKNOWN为-1) 它也是按照惯例来进行计算，所以你看到的结果是进度条往回走。 IProgressMonitor.UNKNOWN不能在子任务进度条中使用，但是在父进度条中使用没有这种问题。取消
上面的例子中，都没有判断进度条是否被取消。在实际使用中，推荐要及时的进行判断。
monitor = ?
try
{
monitor.beginTask(thingyList.size())
for (Thingy t : thingyList)
{
if(monitor.isCanceled())
throw new OperationCanceledException();
t.doSomething()
monitor.worked(1)
}
}
finally
{
monitor.done()
}
The 空进度条
这样可以使调用者不用必须传入monitor,只要输入null 就可以了。
public void doIt(IProgressMonitor monitor)
{
if(monitor == null)
monitor = new NullProgressMonitor();
try
{
monitor.beginTask(thingyList.size())
for (Thingy t : thingyList)
{
if(monitor.isCanceled())
throw new OperationCanceledException();
t.doSomething()
monitor.worked(1)
}
}
finally
{
monitor.done()
}
}
结论
只要遵循这些规则，在使用进度条的时候就不会碰到麻烦。如果不信邪，想当然的用，迟早会出现奇怪的视觉显示，你的客户又要不停的抱怨了。
