The ProgressMonitor class, included in the Swing library
of the Java Foundation Classes produced by Sun Microsystems, has,
in my opinion, several drawbacks. The following ones are
inherent in the technique of passive monitor:
To update the progress bar and the optional progress caption,
the setProgress and setNote methods,
respectively, must be called.
If these methods are called by the computation routine,
they could get called too often, wasting too much time,
or too rarely, causing the application to look "stuck"
(or Not Responding).
A computation, to let being stopped, must call frequently
the "isCanceled" method. But some computations
contain single Java instructions that take several minutes to complete.
For instance, a program could execute another program
and wait its termination, or send a complex SQL query to a DBMS.
During such a wait, obviously, the "isCanceled" method is never called,
and so the calling program looks "stuck".
If a cancelation command is not yet received by the computation
after several seconds, the user cannot change his mind
and cancel his cancelation command.
The following drawbacks are specific of the ProgressMonitor
implementation:
The window caption has the immutable "Progress..." value.
It is not possible to suspend temporarily the current
computation. Actually, a canceled computation cannot be resumed.
It is possible, pressing the OK button or using the title bar controls,
to close the window, while leaving the computation running.
In such a way, the user loses the opportunity to know
the present condition of the computation and to act upon it.
The window is not modal, allowing the user to do
other possibly conflicting operations on the application.
Before the window is open, the user input is not disabled,
allowing the user to do other possibly conflicting operations
on the application.
The user can too easily press accidentally the "Cancel" button;
and there is no way to cancel such a command.
Several computations are a sequence of simpler computations or stages.
Usually, it is easy to say in what stage is the computatation,
and the progress done in the current stage, but it is not easy
to assess the progress in the whole computation.
With a ProgressMonitor, the only ways to cope with such a situation
is to open a new ProgressMonitor for every stage.
Computations running in distinct processes than the
one running the user interface are not handled.
These arguments motivate a different solution to the problems addressed
by the class ProgressMonitor.
Loose requirements of such a solution are:
The window of the monitor window should be highly customizable.
Particularly, every caption should be changeable.
If a computation checks regularly for a breakpoint,
it should be possible to suspend it at such checkpoint,
and then to cancel or to resume it.
There should be no way to close the monitor window,
except when the computation has ended.
The monitor window should be modal, so forbidding the user
to do other operations on the application.
Before the monitor window is open, the user input should be disabled,
so forbidding the user to do other operations on the application.
To update the progress bar and the optional progress caption,
the monitor should access periodically the computation state,
and the computation algorithm should share some state variable,
but should be unaware of access operations.
Even if the computation algorithm does not check for a breakpoint
for a long time, the monitor window should show
a continuous animation.
To cancel a computation should be easy enough to do,
but not too easy.
Even if the computation algorithm does not check for a breakpoint
for a long time, the monitor should allow the user to set or reset
a suspension flag.
It should be possible to handle multi-stage computations with a single
monitor object.
If the computation is done by another process, possibly running
in another machine, the ProgressMonitor class should be able to monitor
such computation.
In addition to these, the following requirements are added:
When the computation is started, a short time is waited, and then,
if the computation is still running and its progress is too little,
the monitor window is opened. Otherwise, the wait and the evaluation are
repeated over again, until the opening of the window or the end
of the computation.
To allow maximum resposiveness to the user interface,
local computations must be run in a thread with a priority level
that is one less than the event-dispatching thread.
For MS Windows