## Printer Device Driver

[prev][next][parent][TOC]

### Alert Handling

There are two types of alerts that can be returned by the printer:

core alerts
extended alerts

Core alerts are those alerts that the OS/2 print subsystem can understand and take action on when encountered. These include cover open, out of paper , and job completed printing.

Extended alerts are those alerts that the print subsystem either does not understand or is incapable of responding to. These alerts often have very specific information sent by the printer to the host PC.

The spooler, by default, enables the core alerts when printing to a bidirectional-capable printer. This allows the spooler to take advantage of the capabilities of the advanced printer. Other applications might be interested in these core alerts.

Applications might also be written that can request additional status or information from a particular set of printers. This additional information can be considered an extended alert. The application must know what extended alerts are supported, and this is done by calling PrtQuery( BIDI_Q _CONVERTER_INFO ) to determine the protocol converter being used. It is up to the protocol converter to publish any extended-alert definitions it wants to make available to applications or printer drivers.

When an application registers for an alert, the spooler enables that alert in the printer by calling PrtSet( BIDI_ENABLE_ALERT ). When the alert is generated, the spooler posts a message to those applications that have registered for the alert. If the alert is an extended alert, the application must call PrtQuery( BIDI_READ_ALERT ) to get the extended-alert information. The format of this returned information is defined by the protocol converter supporting the extended alert.

The spooler mediates what alerts are activated on the printer when multiple clients have applications that register for alerts from the same printer. The spooler only posts an alert to those applications that request the particular alert.

Once an extended alert is activated (by an application calling SplRegister) , if an event occurs that causes the extended alert:

the spooler posts the application that the extended alert has occurred
the application must use the command BIDI_READ_ALERT to get the alert data
The spooler issues BIDI_READ_ALERT to save the alert data until the registered application(s) ask for the alert. However, this data is not be kept indefinitely by the spooler.

The following is done to handle printer alerts:

SplRegister API available to request alert notification from the spooler.

SplUnRegister API available to terminate alert notification from the spooler.

PrtQuery( BIDI_READ_ALERT ) available to applications to read extended- alert information.

When an application calls SplRegister, the spooler determines whether or not the alert being registered is enabled. If it is not enabled yet, the spooler calls the protocol converter with BIDI_ENABLE_ALERT to enable the alert.

When an application calls SplUnRegister, the spooler determines whether or not the alert being unregistered should be disabled. If another application has registered for this alert, the spooler keeps the alert enabled; otherwise, the spooler calls the protocol converter with BIDI_ DISABLE_ALERT to disable the alert.

See the OS/2 Presentation Device Driver Reference for detailed information on these APIs, their syntax, and their parameters.

SplRegister Allows applications to register for notification of events about printers.

SplUnRegister Allows applications to deregister for notification of events about printers.