Hi Gail,
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.
...jay
PS: I hope you don't mind me cc:'ing the PMP mailing list!
--=_ORCL_30736291_0_11919702141927210
Content-Type:message/rfc822
Date: 14 Feb 97 14:25:23
From:"Gail Songer <Gail.Songer@eng.efi.com>" <Gail.Songer@eng.efi.com>
To:jkm@underscore.com
Subject:prtAlertDescription
Return-Path:<Gail.Songer@eng.efi.com>
X-Mailer:Z-Mail (3.2.0 26oct94 MediaMail)
MIME-Version: 1.0
Content-Transfer-Encoding:7bit
Content-Type:text/plain; charset="us-ascii"
Jay,
I have question and in previous conversations you indicated that you would be
willing to try to help me (We all know that in some areas there is just no
hope:)
How much does your application rely on prtAlertDescription to tell the user
what the error really means? I know you are having problems with the hr table
and the alert table being inconsistent. Do you use prtAlertDescription to tell
the user what the real problem is?
Gail
--Gail Songer Electronics For Imaging gail.songer@eng.efi.com 2855 Campus Drive (415) 286-7235 San Mateo, CA 94403
--=_ORCL_30736291_0_11919702141927210--