javax.print.event
package and methods to
register listeners on a service and DocPrintJob
, follows the
familiar listener model used in AWT.javax.print.event.PrintServiceAttributeListener
interface and
installing itself as a listener on a PrintService
as shown in this
example:
public class PrintPS implements PrintServiceAttributeListener { ... pservices[0].addPrintServiceAttributeListener(this); ... public void attributeUpdate(PrintServiceAttributeEvent e){ // Do something if an attribute is updated } ...The
PrintServiceAttributeListener.attributeUpdate()
method is called
when print service attributes change. The service uses the
PrintServiceAttributeListener
interface to decide which events it
supports.
An application can
discover which print service attributes a service supports by using
the same query methods it uses to discover which request attributes
a service supports. For example, to discover if the service
supports the QueuedJobCount
attribute an application calls: service.isAttributeCategorySupported(QueuedJobCount.class)
.
DocPrintJob
: PrintJobAttributeListener
and
PrintJobListener
.PrintJobAttributeListener
is similar to the service attribute
listener: the job reports changes in attributes that implement the
PrintJobAttribute
interface. Usually these attributes are also
print request attributes and are fixed over the lifetime of a print
job. Only a few attributes, such as JobMediaSheetsCompleted
, are
likely to change. Since few clients are interested in this
granularity of detail, and even fewer services support this
capability, clients will most likely use PrintJobListener
to
monitor a job's progress.PrintJobListener
is
easier to use than PrintJobAttributeListener
because it delivers
simple messages, such as printJobCompleted
or printJobFailed
. The
interface has only six methods, each of which reports a significant
but simple piece of information as an event. As a convenience, the
adapter class, PrintJobAdapter
, provides default implementations of
these six methods.
One message in
particular: printJobNoMoreEvents
is unusual but useful. A client is
often interested in knowing if a job has finished or failed. If
possible, a service should deliver such "terminal" events, but
sometimes the service cannot be sure if the job finished or failed,
and a "completed" message is misleading in this case. For example,
a job might be spooled to a network print service that has a queue
that's not visible. In this case, the "no more events"
message is not sufficient to say that the job has succeeded, but
the client can at least infer that it is not known to have failed.
The following example demonstrates adding a listener that monitors
printJobNoMoreEvents
messages:
public class PrintPS extends PrintJobAdapter{ ... pj.addPrintJobListener(this); ... public void printJobNoMoreEvents(PrintJobEvent e){ // Do something here } ...