Gail,
> > If a vendor chooses to add two alert entries for the printer-stopping
> > low toner condition, then the offline alert should have its description
> > string clearly state that the reason for going offline is due to the
> > low toner condition, and not simply say "Offline" (as so many do now).
> >
> > Is this a fair compromise?
>> If we are going to have multiple "types" of offline, then the other variables
> in the alert table probably should reflect the differences. At a minimum the
> offline alert should have different prtAlertLocation's based on the "type" of
> offline. To me a better implementation would have different alert groups and
> alert group indexes as well.
You're absolutely right. Thanks for pointing this out. In the (now infamous)
case of a critical low toner condition, the (single) "Offline" alert would
not only have a description saying "Low toner", but also have the alert
group point to the Marker group, etc.
> This could take a lot of space in an imbedded system where space is precious,
> either code space to create the entry and then ram space to store it or extra
> entries in a table. Additionally this could clutter up the alert table with
> multiple offlines and we should definatly try to hold the size of the table
> down.
I agree, and I thought other printer vendors would agree regarding the
embedded space requirements when multiple alerts are posted for a single
condition. I was hoping this new compromise could be the "best of both
worlds".
> Given that you really want to inform the user of why the printer is not
> printing, I like your previous suggestion better. One alert describes the true
> state imposed by the alert(one alert that is tonerlow, critical and one that is
> tonerlow wraning). This also seems to be more consistent with other critical
> errors. It is annoying that I have two alerts for basically the same engine
> event, but to me, it is cleaner then the above.
Thanks for your support.
...jay