Alec
Thu Sep 29 17:43:43 CDT 2005
Hi Brian,
Thanks for the input. Yes, the problems presented by this situation are
varied. In my case, I had users reporting that the 2nd, 3rd, etc. pages of
a report (which unbeknownst to them was actually multiple VFP reports
printed in immediate succession) were printing super small using only the
upper left 1/4 of the page and only page #1 (the first report) was correct.
I discovered that the default printer driver was being used for subsequent
reports in the same print job. Since different printer drivers are designed
for differing printer resolution capability; use driver "A" on printer "B"
and viola; "Houston we have a problem"!
I have also had to mess with maintaining sequential page numbers across
multiple REPORTS. I solved the issue by setting a variable before and
between the running of each report, and specifying the page number in the
report as = myvar+pageno(). It is interesting that in VFP 9 they address
the page x of x issue, but clearly doing this across multiple reports is a
bit more complex and changing the printer driver used within the same print
job (as you explained) only compounds a problem that is otherwise
solvable....
Alec
"Brian Hiatt" <BrianHiatt@discussions.microsoft.com> wrote in message
news:2A3C3FE1-27A8-47FA-80CF-F70107F6FFA0@microsoft.com...
> Alec,
> I have the same issue. Our system requirements are such that we must have
> Page XX of XX across all the reports so from a page numbering perspective
> it
> looks like a single report (novel idea!). How we do this is print all the
> reports to file and at the end of each one we grab the _pagetotal to a
> variable. We then add all these together to get the grand total number of
> pages. We also add all the page numbers to get the "starting page" for
> each
> report to variables. This becomes quite complex but we have it working
> well
> after MUCH testing.
>
> We then send the reports in the same order with PREVIEW PRINT PROMPT so
> the
> user can view then and print them if needed.
>
> Our users have a problem if they have a default printer set as printer A
> and
> when they print from the preview they select printer B to actually print.
> What happens is that the page totals were counted using Printer A but the
> report is printed using Printer B so the page numbers are different. We
> will
> get strange results near the end of the last report we will have page 51
> of
> 48 due to the way we tally the page numbers.
>
> We have resorted to your solution by issuing RUN control printers at the
> beginning of the print program and asking the user to set their default
> printer to the printer they wish to print to.
>
> I wish I could help but wanted to attach to this thread so I am notified
> of
> anybody that replies. If you figure out anything let me know.
>
> Best Regards,
> Brian Hiatt
>
> "Alec" wrote:
>
>> Hi Lee,
>>
>> Thanks for the reply. Using the SET PRINTER TO command essentially takes
>> the same or similar approach as using the SYS(1037) command. Both
>> approaches, set the printer BEFORE the report is run. It works, but is
>> kind of clunky. If the user just wants to preview the report and not
>> print
>> it, why would we force them to select a printer first? It seems to me
>> that
>> if a series of reports are all part of the same print job and are all
>> going
>> to the same printer, they should all use the driver for that printer!
>> But
>> that is clearly not the case.
>>
>> Set you default printer to a LaserJet then run some VFP code similar to:
>>
>> REPORT FORM x1 TO PRINTER PREVIEW PROMPT NOPAGEEJECT && user selects
>> dot
>> matrix printer
>> REPORT FORM x2 TO PRINTER && report goes to dot matrix printer but uses
>> the LaserJet print driver.
>>
>> As you can imagine the results can be very unpredictable.
>> --
>>
>> Alec
>>
>>
>> "Lee Mitchell" <Leemi@online.microsoft.com> wrote in message
>> news:xqXMvsRxFHA.628@TK2MSFTNGXA01.phx.gbl...
>> > Hi Alec:
>> >
>> > I think you need to use the SET PRINTER TO NAME command before both of
>> > the
>> > reports. See this article for more information:
>> >
>> >
http://support.microsoft.com/default.aspx?scid=KB;EN-US;162798
>> >
>> > I hope this helps.
>> >
>> > This posting is provided "AS IS" with no warranties, and confers no
>> > rights.
>> >
>> > Sincerely,
>> > Microsoft FoxPro Technical Support
>> > Lee Mitchell
>> >
>> > *-- VFP9 HAS ARRIVED!! --*
>> > Read about all the new features of VFP9 here:
>> >
http://msdn.microsoft.com/vfoxpro/
>> >
>> > *--Purchase VFP 9.0 here:
>> >
http://www.microsoft.com/PRODUCTS/info/product.aspx?view=22&pcid=54787e64-52
>> > 69-4500-8bf2-3f06689f4ab3&type=ovr
>> >
>> > Keep an eye on the product lifecycle for Visual FoxPro here:
>> >
http://support.microsoft.com/gp/lifeselectindex
>> > - VFP5 Mainstream Support retired June 30th, 2003
>> > - VFP6 Mainstream Support retired Sept. 30th, 2003
>> >
>> >>Hi All,
>> >
>> >>Ever experienced super small 1/4 size printing on a report?
>> >
>> >>In circumstances where you use the PROMPT and NOPAGEEJECT options on
>> >>the
>> >>REPORT FORM command so that the user can select the printer desired and
>> >>so
>> >>that a subsequent report will be part of the same print job, the
>> > subsequent
>> >>report will always use the default printer driver no matter what
>> >>printer
>> > the
>> >>user selected. IOW, the PROMPT option of the report command only
>> >>effects
>> >>that specific report and not all the reports that are part of the same
>> > print
>> >>job. Example:
>> >
>> >>REPORT FORM A1 TO PRINTER PROMPT NOPAGEEJECT NOCONSOLE
>> >>REPORT FORM A2 TO PRINTER NOCONSOLE
>> >
>> >>If the user selects any printer other than the default when prompted
>> >>the
>> > two
>> >>reports above that are both part of the same print job will be printed
>> >>to
>> >>the same printer using different printer drivers for the first and
>> >>second
>> >>reports. (Keeping them part of the same print job is really handy when
>> >>printing to a PDF file) . Using the wrong printer driver for a report
>> > going
>> >>to a printer can give you strange results. Is there a way to force
>> > multiple
>> >>reports that are part of the same print job and all going to the same
>> >>printer to use the printer driver that is related to the PROMPT
>> >>selection
>> >>made on the first report?
>> >
>> >>I have resorted to placing a sys(1037) in code just before my report
>> > rather
>> >>than using the PROMPT option on a REPORT FORM command, to change the
>> > default
>> >>printer. It is a kludge and does not present as nice a user
>> >>interaction
>> > as
>> >>the prompt option but it works. This seems like a minor bug to me...
>> >
>> >>Anyone have a new information or ideas?
>> > --
>> >
>> >>Alec
>> >
>>
>>
>>