Path: utzoo!attcan!telly!lethe!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!dsinc!netnews.upenn.edu!msuinfo!convex.cl.msu.edu!jap
From: jap@convex.cl.msu.edu (Joe Porkka)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Wb2 questions, ECS Denise
Message-ID: <1990Dec21.182047.12630@msuinfo.cl.msu.edu>
Date: 21 Dec 90 18:20:47 GMT
References: <632@cbmger.UUCP> <1145@cnw01.storesys.coles.oz.au> <650@cbmger.UUCP> <1990Dec20.131346.23479@marlin.jcu.edu.au> <663@cbmger.UUCP>
Sender: news@msuinfo.cl.msu.edu
Organization: Michigan State University
Lines: 29

peterk@cbmger.UUCP (Peter Kittel GERMANY) writes:

>In article <1990Dec20.131346.23479@marlin.jcu.edu.au> glmwc@marlin.jcu.edu.au (Matt Crowd) writes:
>>
>>BTW, have you fixed the printer driver feature that makes the
>>requester for the printer being off line take so long to come up? I
>>haven't tested this yet.

>may cancel the output at any moment. But what if Workbench was 
>closed?
Then you open it first :-)
Actually in the printer driver that I wrote, it opens a window on the
wbscreen (for another reason). If the screen was closed, then it opens -
the only problem being that the WorkBench interface gets lost. I suspect
that doing an OpenWorkbenchScreen() first would fix it.

>The timeout value is placed among the very first bytes in a
>printer driver. If you take out the RKMs, it shouldn't be too
>difficult to patch your driver for more convenient values.

Perhaps you couldclarify this point. I have written my own custom printer
driver and the exact way the timeout is used is not clear.
My only guess is that it is the time between sending a packet to
the (parallel|serial).device and recieving the reply.
I think that maybe the #?.device needs to be enhanced to
give info about how much time has passed since it was able to 
send data, or have the timeout depend on the packet size, or simply
do not send packets greater than some x number of bytes - all to
allow for a small timeout (say 5 or 10 seconds).