：转载时请以超链接形式标明文章原始出处和作者信息及

摘要
使用进度条监视器并不像看起来的那么简单，在使用时很容易犯错。这取决于各种因素，像底层实现，显示方式，是否被设定固定数目的工作条目，是否使用了SubProgressMonitor 嵌套，等等。结果可能是xx没问题，也可能是 让人挠头，或者彻底不可用。

本文将指导怎样有效的使用进度条监视器。
--------------------------------------------------------------------------------

使用进度条监视器
在许多简单的惯例中，有一条是“只知道所知道的，并且xx于此”。这就是说，不能假设xx了解你所不知道的事情。就像，你不能想当然的认为进度条监视器就是你在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() {zh1}被执行。
子任务用代理使用进度条监视器
beginTask()被调用不要多于一次，这种错误经常发生。进度条被传给子任务，子任务没有意识到进度条已经执行了beginTask()，还是按照规定的契约，执行beginTask()方法。除非子任务对此了解，否则传递进度条实例是十分错误的。一般情况下，接受到进度条实例的代码应该假设此实例自己会遵守beginTask()/done()契约。如果子任务也需要进度条，就应该使用SubProgressMonitor作为代理，封装传入的进度条实例。

如下为样例:

monitor = ?// 获取进度条实例try { monitor.beginTask(? 
 // 执行任务 ?BR> // 创建一个子任务 someThing.doWork(new SubProgressMonitor(monitor,?) 
 // // 创建右一个子任务
  anotherThing.doWork(new SubProgressMonitor(monitor,?) }finally { monitor.done() }每一个doWork()调用得到一个新的SubProgressMonitor 实例。
管理条目个数
如果确实不知道确切的条目总数，不要随意猜测数字。如果猜大了，数字会走的很慢，然后突然到达{bfb}；如果猜小了，那么会很快到达终点，并且永远停在那里。没有确切总数的话，填写 IProgressMonitor.UNKNOWN就可以了。
怎样调用 beginTask() 和worked()
通常你可以通过两种方式得出你究竟要处理多少条目：一是调用许多不同的方法来得到结果，二是在一个集合中为每一个实例调用同一个方法。每种方式你都可以知道总的条目数（方法的个数或集合的大小）。

你应该将按比例测量出你的总数。如果总数是3 (每个条目工作为worked(1))，你可以把比例定为1000，总数为3000， (每个条目工作为worked(1000) ). 当你要通过SubProgressMonitor将工作传递到子任务中，就要应用这种方式。因为子任务内部的总数和外部是不同的，也许比你定的总数大许多。你要给它们一些缓冲润滑的空间。这样可以避免进度条执行时视觉上的便扭。

样例:

monitor = ?
 // 取到进度条监视器int total = 3 // 总数为3try { 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 + 2try { 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)  } // {zh1}一条  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() } }结论
只要遵循这些规则，在使用进度条的时候就不会碰到麻烦。如果不信邪，想当然的用，迟早会出现奇怪的视觉显示，你的客户又要不停的抱怨了。

本文来自CSDN博客，转载请标明出处：