#Printer Handler
7 messages in this thread
Gene, A few of the programs I have will work this way, but many of them won't.
I've tried taking the printer offline and even turning it off. The requestor
comes up and I click 'CANCEL' and off we go again. I have done this for as much
as 1 hour as an experiment. It seems like 'RETRY' and 'CANCEL' lead to the same
routine. It makes no difference. Later, Greg
Greg:
That is the PROGRAMS fault not AmyDos's! Amy honors the cancel but
when the program does not but keeps asking for the resource then the Amy
considers it to be a new request. This will go on forever. It really has to
be that way since the program obviously does not have a means of aborting the
request.
73,
bill
Bill,
I realize that it is the program's fault. I just want to be able to do
something about it, irregardless of what program I am using. I think Ben Blish
has the best idea, that the handler, after receiving the abort command,
reroutes the rest of the file to the bit bucket. The program then thinks that
the dump has finished normally after just a few seconds. I hope he gets a
chance to work on it one of these days.
Later,
Greg
Greg:
That is a good solution and might not be a bad provision to incorporate
in the driver code except that it would be a kludge to compensate for a bad
program. A utility on the otherhand would be appropriate.
73,
bill
Well, I would like to see it set up so that it would install itself in DOS like
Blitzfonts does, so that it would be there no matter what program calls the
printer.device. Later, Greg
Greg:
That part should not be any problem (thanks to AmyDos).
73,
bill
Oh well, it was worth a try. It seems to me that most of th programs I tried,
worked. Obviously it's up to the individual program to handle (or not handle)
the error code returned from a print. I guess I was just lucky…
Gene.