bin@primate.wisc.edu (Brain in Neutral) (01/11/91)
Programmer's Guide to MultiFinder goes to a lot of trouble to caution us not to let embedded services and background tasks take over the machine, so that the responsiveness of the foreground application is not compromised. This seems reasonable. "So," I say to myself, "what is the worst offender against this principle?" Well, of course the obvious answer is...PrintMonitor, one of Apple's *own* products. When you're printing stuff in the background and the page starts to go through the printer, you can just forget about doing anything until the page is just about all the way out. Just what is PrintMonitor's problem anyway? Isn't it following Apple's guidelines? Is there some resource that can be edited to get it to be a little more cooperative? Or is this behavior simply something to do with waiting for a response from the printer at certain times such that it can't let go until the printer says something back? -- Paul DuBois dubois@primate.wisc.edu
urlichs@smurf.sub.org (Matthias Urlichs) (01/13/91)
In comp.sys.mac.programmer, article <3724@uakari.primate.wisc.edu>, < < Just what is PrintMonitor's problem anyway? Isn't it following Apple's < guidelines? Is there some resource that can be edited to get it to < be a little more cooperative? Or is this behavior simply something < to do with waiting for a response from the printer at certain times < such that it can't let go until the printer says something back? PrintMonitor uses the LaserWriter's AppleTalk/PAP code, which probably wasn't designed with background printing in mind. The problem is more or less inversely proportional to the quality of the wire(s) to your LaserWriter. Give it a thousand PINGs with InterPoll -- what's the round trip time and how many packets get lost? What LaserWriter model are you using? -- Matthias Urlichs -- urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de /(o\ Humboldtstrasse 7 - 7500 Karlsruhe 1 - FRG -- +49+721+621127(0700-2330) \o)/