>Right now we use the prtAlertDescription text exactly AS IS, so yes, this
>string is pretty crucial for us. I've realized all along, though, that all
>it takes is for one vendor to use "silly" strings, and then we'd have to
>start using the alert code (along with the location data) to generate a
>string ourselves.
>
>But, for now, we use the prtAlertDescription string directly from the printer.
HRL - Because prtAlertDescription is localized, some embedded controllers
HRL - will find it impractical to provide much detail in this object.
HRL - Many controllers will attempt to optimize the use of console and
HRL - alert description strings to reduce translation cost and storage.
HRL - So, while it is OK to use prtAlertDescription exactly AS IS, it
HRL - should be stressed that this string is not necessarily sufficient
HRL - to fully describe the condition. prtAlertGroup and ...GroupIndex
HRL - should definitely be considered part overall event message when
HRL - presenting the information.
HRL - Our printer, for example, will contain the words "Paper Jam"
HRL - in prtAlertDescription while the prtAlertGroup will make it
HRL - obvious where the jam is (Input, Output, Media Path etc.).
HRL - The prtAlertDescription will not contain words like
HRL - "Paper Jam Input 3", for example.
HRL - Of course, the prtAlertLocation is a vendor defined field
HRL - which can be used to *pinpoint* the alert and post verbose
HRL - messages should the software understand which printer it is
HRL - dealing with and what that vendor's particular LOC definitions
HRL - are.
Harry Lewis - IBM Printing Systems