Normally when a Job
is running, it is necessary to periodically update the user to let them know the state of progress. By default, if a Job
provides no information, a generic busy
indicator is shown. When a Job
is executed, it is passed an IProgressMonitor
object, which can be used to notify the user of progress (and provide a way to cancel the operation). A progress monitor has a number of tasks, each of which has a total unit of work that it can do. For jobs that don't have a known amount of work, UNKNOWN
can be specified and it will be displayed in a generic busy
indicator.
HelloHandler
and go to the execute()
method. In the run()
method of the inner Job
, add a beginTask()
at the beginning, and a worked()
method in the loop after each second's sleep, for five iterations. The code will look like the following:protected IStatus run(IProgressMonitor monitor) { try { monitor.beginTask("Preparing", 5000); for(int i=0;i<5;i++) { Thread.sleep(1000); monitor.worked(1000); } } catch (InterruptedException e) { } finally { monitor.done(); } MessageDialog.openInformation(null, "Hello", "World"); return Status.OK_STATUS; }
for(int i=0;i<50;i++) { Thread.sleep(100); monitor.worked(100); }
When running a Job
, the progress monitor can be used to indicate how much work has been done. It must start with a beginTask()
method—this gives both the total number of work units as well as a textual name that can be used to identify what's happening.
If the amount of work is unknown, use IProgressMonitor.UNKNOWN
.
The unit scale doesn't really matter; it could have been 50 or 50,000. As long as the total number of work units add up, and they're appropriately used, it will give the user a good idea of the operation.
Don't just report based on the number of lines (or tasks). If there are four work items but the fifth one takes as long as the previous four, then the amount of work reported needs to be balanced; for example, provide a total of 8 units, with 1 unit for each of the first four and then the remaining four for the fifth item.
Finally, done()
was called on the progress monitor. This signifies that the Job
has been completed, and can be removed from any views that are reporting the status. This is wrapped inside a finally
block to ensure that the monitor is completed even if the Job
finishes abnormally (for example, if an exception occurs).