SYS(1500, '_MFI_SYSPRINT', '_MFILE')

No, this is not easily possible if you don't know how to intercept Windows dialogs...

Easier could be to call Win32 API functions directly which allows to set the printer properties and returns the last button pressed: http://www.news2news.com/vfp/?example=531
http://www.news2news.com/vfp/?example=384&function=591&PHPSESSID=a4b1762b8ab7ae219d12bd7c86a8502b

Will take a closer look, hopefully tomorrow.  Will be back to you soon. Thanks for your quick reply.

Looking at the code the answer isn't useful for you probably... It allows to select the printer and set printing properties but I don't see the possibility how to force this printer to be used for the next VFP report. You'll need to call the SetPrinter API function...  It means a lot of investigations.

Some additional info is here: http://www.tek-tips.com/viewthread.cfm?qid=1281712

Make sense.  By mean time, I read on some forum using NoPageEject in report form, except last report.  I read also that page # keep increasing.  Is this a possibility, using NoPageEject, to solve my problem ?  If so, will I have to manage page # to be reset between each report and, if so, how do I do that ?
If NoPageEject is a solution, I will investigate my code on how I can check if processed report is last or not, and that should be it :)

NOPAGEEJECT is useful in one particular case only: When you use it the next report printed is added to the open print job. You can use NOPAGEEJECT to set up duplex printing, that is, printing on the reverse side of a previous report. (In other words the next report cannot continue in the middle of page printed by the previous report.)

I am just not sure if NOPAGEEJECT resets _pageno or not... I would guess the _pageno is reset for each report except the case NORESET keyword is used in REPORT FORM command.

You may set any initial value as the initial page number by
_pageno = n
before the REPORT FORM ... NORESET command

Some useful info could be in FoxyPreviewer source code (http://foxypreviewer.codeplex.com/).

Looking at your previous question this one is related probably... So another solution would be PRINTJOB - ENDPRINTJOB:

PRINTJOB
  REPORT FORM Report1 TO PRINTER PROMPT
  REPORT FORM Report2 TO PRINTER
  REPORT FORM Report2 TO PRINTER
ENDPRINTJOB

The first report will ask for printer settings which are then used for all reports in the PRINTJOB.  You don't need any special settings in the first report etc.  NoPageEject and/or NORESET usage depends on your decision.

NOPAGEEJECT does not suppress the _pageno reset as I expected.

Will sure try it ASAP :)  Keep you posted .

One more thing. Above code does not stop the PRINTJOB when user cancels the printer selection from the dialog displayed by the  PROMPT.

A way how to ensure the report was printed is described here: http://portal.dfpug.de/dfpug/Dokumente/FoxTalk/FoxTalk2000/FT200012_4.PDF

If you use REPORTBEHAVIOR 90 then the scenario is a little bit different but you have many more possibilities...

More info: http://msdn.microsoft.com/en-us/library/ms965279.aspx
http://msdn.microsoft.com/en-us/library/ms965281.aspx
http://www.code-magazine.com/articleprint.aspx?quickid=0404032&printmode=true
http://fox.wikis.com/wc.dll?Wiki~ReportListener

Sorry about delay, was off office last week.  Implemented PrintJob.   Weird result.  My first report prints as expected, all the others are forwarded to my default printer.  Was thinking to make Set printer to ... but this will not make user's preferences to follow.    
My thinking is I'm missing something for PrintJob - EndPrintJob to work, am I wrong

It seems to be my mistake. Sorry. I would swear it worked for me on XP computer...

I've tested the PRINTJOB - ENDPRINTJOB code now again under W7 and it prints the second report to the default printer...

To force the selected printer for successive reports you have to add NOPAGEEJECT keyword to all reports (except the last one). And you may remove PRINTJOB - ENDPRINTJOB which seems to be useless now.

FoxyPreviewer mentioned in one of my previous messages could give you additional options. It, of course, slows down the printing.

Weird.  NoPageEject is working, but abnormaly :(  
First report output correctly with user' preferences (mainly black on a color printer).  All other report, within my loop, output to same selected printer, black, but 4 times bigger, so only top left corner print, as report take 4 times the place !!!
Did test on two different printer, one Xerox and one Brother.  Does it make same pattern on your side ?  If not, must be something wrong on my side :S

Thanks, for your help

It seems we've touched untested parts of VFP...

It prints OK over HP Universal Printing PCL 5 (v5.5.0) driver (HP Color Laser Jet CM2320 MFP connected to the print server) in my case.

The 4 times bigger printout points to the different DPI setting on your printers which in conjunction with shared Device contexts among print jobs could cause this abnormality. But why?

You should also remove possibly saved printer environment info from all report layouts -  display Report Properties and uncheck the appropriate check box.

Check box is uncheck on that report (Report, Printer Environment).

It should be unchecked on all reports.

You could try to swap the first two reports - if the problem is in reports then it should print 4 times smaller output...

Oh, one important missed point I did not told you yet: my issue occurs when printing multiple "same" report, using different select.  My report name is Extras2.frx, which basically show a billable timesheet.  I'm trying to print a bunch of timesheets to printer, but do not want to prompt each of them.

OK, I am also testing it on one report printed twice for different set of records...

And both the HP and Canon printer works for me without problems. If I set double sided printing and B/W on the prompt then all (two) reports use the same setting.

Two REPORT FORM commands generate just one entry in the printer queue and the reason why it should change DPI or printer output resolution is unknown to me.

I've tested both REPORTBEHAVIOUR 80 and 90.

I've also removed PRINTJOB - ENDPRINTOJOB commands from my code.

So, could you test it on different printer/printer driver?  Or could you try to change the output to e.g. PDF?

But the multiple call of one report can be replaced by an additional Group band in your existing report layout and then one REPORT FORM command is enough.

You have to add one more column to your data and set its value based on the new groupping. The Group band definition should have just one seting: "Start the group on a new page No. 1". The report engine should do the rest.

Did test on another development PC: working on it !!  So investigating further.  One idea for now, is my OS is english and the other one is french.  We're now trying to make test on another english development PC.  Will keep you posted...  
Another point, on my tests, printer is a shared printer from a terminal server.

oops, new interesting stuff.  Issue is not related to PC directly, it is related to default printer.  On my PC, default is Adobe PDF while the "working PC" was used printer for test.  So, we made the "working PC" default printer to Adobe PDF and that PC failled also.  Looks like even if NoPageEject make printer "the same", default printer takes over starting at second print...  Does it make any sense to you ??  Can you make that test on your side, that is make Adobe PDF default printer ?

Really interesting...

If I set PDF Creator (from www.pdfforge.org) as the default printer it still prints correctly on other (HP) printers but there are many "PDF printers" available on the net so you can use another one.

Agree with you.  Problem is users.  We tried some other PDF printer, as PDF995 (same error), CutePDF (was ok).  Users may have some PDF printer that "are not compatible.  On same thought, if my default printer is a Xerox (for example) and I want to create PDF, if I'm using Adobe PDF (one installed on my development PC), first page output correctly, other page output "reduced by 4), so reverse problem...
So from this point, I'm thinking about using Set("Printer",2) to get actual default Windows printer, and then use Set Printer to Name "MyUserSelection".   At the end, would use Set Printer to Name "BeforeDefaultPrinter".  I remember using Set Printer To Name in the past, and was working.  Not sure about what's happening now, but no result: default Windows default stays the same.  Is Set Printer to Name still working on Win 7 64 ?

Yes, SET PRINTER TO NAME is working on Win 7/64. The known problem is printer name containing national characters which fails sometimes.

So, on your PC, win 7/64, when you place a SET PRINTER TO NAME, set("Printer",2) is changing ?   That would make sense, and I think this is where every thing start misfunctionning on my side: this was working before on my side.  For unknown reason, now it is not.  Tried it on another PC here, same result: not changing.

I'll test it this evening

SET PRINTER TO NAME  set("Printer",2)
changes the printer used by VFP to the default Windows printer on my Win 7/64 PC.

If the default printer is set as Software602 Print2PDF then following commands print correctly:

  REPORT FORM files TO PRINTER PROMPT NOPAGEEJECT  && OKI c301 printer selected
  REPORT FORM files2 TO PRINTER

So some drivers/printers are less compatible with FoxPro...

ok, but my understanding is SET PRINTER TO NAME set("Printer",2) make default VFP printer as Win 7/64 PC.  Is SET PRINTER TO NAME "user selected printer" make it also Win7/64 PC default printer?

No, SET PRINTER TO NAME "user selected printer" does not change Windows default printer but API function exists: http://www.news2news.com/vfp/?function=940

Discouraged, either way SET PRINTER TO NAME or managing Windows default printer, both link to possibility for me to get use selected printer in REPORT FORM TO PRINTER PROMPT !!!

Hopefully, there is a way to get the user selected printer out of a TO PRINTER PROMPT !  I know I cannot use the GETPRINTER() function as this function does not allow user's print preferences...

Well, I browsed both link.  By checking "Report Environment" under Report menu, I can have access to User selected printer off the REPORT FORM TO PRINTER FORM.  When under development, opening report file as a table is easy as we know where file is.  However, under EXE mode, when report file is part of project, this is another story.  Is there a magical way I can open report file as a table when that file is within project or I will have to place file "outside project" to make it accessible under the EXE mode ?

The report file inside project is Read only and you may open it by USE command (the path is ignored).
If you would need to write some values into the report (FRX+FRT) then you have to copy it outside the EXE by e.g. COPY FILE command and you have to assign a new name to the report.

Sorry about taking so long so reply...  Not sure what happened, but unfortunately, selected printer "no longer" appears in EXPR report field :(  As before, if I link all report form with NoPageEject, first report output correctly, other are "4 times" because my Windows default printer is Adobe PDF.  As I have some customer using that soft, I imagine some other weird results, ...  Things work good when I place a SET DEFAULT TO NAME &UserSelectedPrinter, but point is I need which one he selected.   By placing report outside my application I can read/write EXPR field, so this is working.  For now, only point missing is getting what user selected...

Hmm.... it sounds like a dead end...

OK, the only option seems to be:
1) Save the default VFP printer
2) SET PRINTER TO NAME ... before each print
You have to select the printer which does not cause problems and such printer must be recorded in some configuration for every single PC
3) Then you may use the set of REPORT FORM ... NOPAGEEJECT commands having the PROMPT in the first one.
4) And finally restore the original default VFP printer

Of course, you can still play with Device context API functions and investigate how to use the created printer DC in VFP report.

I also believe the ReportListener object (http://msdn.microsoft.com/en-US/library/ms954019(v=vs.80).aspx) should allow to bypass the "4 times" problem but it means a lot of work.

BTW, you should ask Adobe why their PDF driver behaves this wrong way. But I can imagine the answer...

More than excellent comprehensive support.

I will involve http://foxypreviewer.codeplex.com/ in my application, force user to select printer before enabling him to command multi-select reports prints.  That should "makes the job", and in my case, slightly better using FoxyPreviewer :)

1000 thanks to you.