Xref: utzoo comp.windows.ms:195 comp.windows.misc:1002
Path: utzoo!utgpu!attcan!uunet!lll-winken!lll-lcc!ames!mailrus!cornell!uw-beaver!microsoft!jimw
From: jimw@microsoft.UUCP (Jim Walsh)
Newsgroups: comp.windows.ms,comp.windows.misc
Subject: Re: Continuing Windows Questions
Keywords: windows, printer drivers
Message-ID: <263@microsoft.UUCP>
Date: 13 Jan 89 21:58:20 GMT
References: <629@usl.usl.edu>
Reply-To: jimw@microsoft.UUCP (Jim Walsh)
Organization: Microsoft Corp., Redmond WA
Lines: 30

In article <629@usl.usl.edu> pcb@usl.usl.edu (Peter C. Bahrs) writes:
>Just thought that I would post some continuing questions and comments 
>that I have concerning MS Windows.  I have never really obtained sufficient
>answers for these.
>
>- How come the spooler will only queue up to 20 jobs?  Can I override
>this? How did you find out, if yes?
>  - I have an application that prints out data reports.  Reports can
>    be N pages long and the user may only want to print page N so they
>    want to be able to pick any pages.  Therefore we print each page
>    as a job.  Seems to be a fairly simple yet standard request???
>
   It probably isn't a good idea to print separate pages of a report as
separate jobs, whether in the Windows environment or not.  One simple
reason is that the print spoolers on many networks like to insert blank
pages, header pages, or other goodies between jobs.  Thus, if your app was
run on such a network, your could get 2 or 3 sheets of paper for each
page of your report - not what you (or the user) would probably want.

   Thus, you should probably try to modify your printing code to write out
the entire data report as one job.  I would also think that it would be
somewhat counter-intuitive to a user to see 10 or 20 jobs in his print
spooler queue when he printed one report, especially if he had multiple
Windows apps generating output to the spooler (jobs could be inter-mingled).

-- 
Jim Walsh                       jimw@microsof.beaver.cs.washington.EDU
Microsoft Corporation           jimw@microsof@uw-beaver.ARPA 
                                jimw@microsof.UUCP
The views expressed herein are not necessarily mine, let alone Microsoft's...