Xref: utzoo comp.sys.mac.programmer:20551 comp.sys.mac.system:2774
Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!usc!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!bin
From: bin@primate.wisc.edu (Brain in Neutral)
Newsgroups: comp.sys.mac.programmer,comp.sys.mac.system
Subject: MultiFinder Programmer's Guide question 4
Message-ID: <3724@uakari.primate.wisc.edu>
Date: 10 Jan 91 18:54:19 GMT
Organization: Cafe Limbo
Lines: 20

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