Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Chris Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Reports - I know this probably has been asked a million times! 1

Status
Not open for further replies.

AlastairP

Technical User
Feb 8, 2011
286
AU
I am just trying to get my head around report printing options.

I select the printer in the drop down list

The order I do this is:

1. GETPRINTER()
2. A select statement
3. call report form - use behaviour 90

but the report always prints to the same printer.
I even tried changing the default printer in the windows control panel, but this had no effect

I tried this FAQ faq184-581, but it still did the same.

I had the option unticked to remember print settings in the report designer properties.

Any help would be appreciated


 
Alastair,

This is the classic symptom of the printer environment being saved with the report.

With VFP 8.0 and below, you would normally follow the steps in the FAQ you quoted. I don't know why that didn't work for you.

But as you have VFP 9.0, the solution is simpler. Open the report in the Report Designer, and un-tick "Printer Environment" in the Report menu. Then save the report. (There's a screen shot here: Trouble-shooting a Visual FoxPro application.)

That should do the trick, but if it doesn't, report back.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy
 
The step you leave out of your summary is probably the most important:

After GetPrinter(), you must SET PRINTER.

Getprinter() alone is nothing but free U/I letting the user choose a printer. It doesn't do anything to *set* that printer.
 
While the following may be somewhat Over-Kill I use the following to temporarily change the workstation's Default Printer so that my print hardcopy will go where desired.

Code:
* --- Determine Current Workstation Default Windows Printer ---
lcDefaultPrinter =  SET("PRINTER",2)

* --- Now Get New Printer Name ---
lcNewPrinter = GETPRINTER()
IF !EMPTY(lcNewPrinter)
  * --- Use Windows Scripting To Change Workstation Default Printer ---
  ONET = CREATEOBJECT("WScript.Network")
  ONET.SetDefaultPrinter(lcNewPrinter)

  * --- Set VFP Printer Name ---
  SET PRINTER TO NAME (lcNewPrinter)

  * --- "Print" Report Form To Wherever ---
  SELECT RptFile
  GO TOP
  REPORT FORM (mcFRXFile) TO PRINTER NOCONSOLE

  * --- When Done Printing - Use Windows Scripting To Restore Original Default Printer ---
  ONET.SetDefaultPrinter(lcDefaultPrinter)
  RELEASE ONET

  SET PRINTER TO NAME (lcDefaultPrinter)
ENDIF  && IF !EMPTY(lcNewPrinter)

I have never been 100% certain if I REALLY have to change the Workstation's Default Printer also, but by doing so I have always had the printouts go where I need them (unless the FRX needed 'hacking').

Good Luck,
JRB-Bldr
 
After GetPrinter(), you must SET PRINTER.

That's the answer. I admit I didn't notice it myself.

So the code should look something like this:

Code:
lcPrinter = GETPRINTER()
IF NOT EMPTY(lcPrinter)
  SET PRINTER TO NAME (lcPrinter)
  REPORT FORM .... etc.
ENDIF

The reason for tesing for an empty name is in case the user cancels out of the printer dialogue.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy
 
JRB, colleague, Thank you!
I totally forgot about this trick with Windows Scripting/Network to manage the default printer! I used it last time some 6-8 years ago (in VFP7), and it did work!

(Funnies on the footnote ;-): There were customers back then, though, that still used WinNT 3.5x and Win95 machines, and I can't recall whether it worked on the latter, but it sure didn't on the former, IMS: something to do with the H file or somethin'... So I had to bend over backwards for these folks to get them to change the output printer on run-time.)

Regards,

Ilya
 
JRB,

Have I understood your code right? You are saying that, in order to specify a printer in VFP, you should change the workstation default printer? (I assume that means the default printer as seen by Windows?)

If so, that seems like bad behaviour to me. An application should never make a global change in order to serve its own local needs. What if the user starts the report in VFP, then switches to another application, and starts printing something else, in the expectation that it will go to the default printer - which it won't?

It seems to me that you can remove all your code for setting and restoring the Windows default printer, and it would still function in the same way.

If I've misunderstood, my apologies.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy
 
Mike - you have interpreted the code correctly.

And I did say that it might be Over-Kill and part of it might not be totally necessary.

But since the VFP report printouts are quick and then the workstation Default printer is immediately restored to its original value, my clients have never mentioned running into problems.

I guess that once I had the code in place and working I did not go back and try to minimize it to see if it would work as intended without the 'change workstation default printer' part.

I'll have to try it out.

Thanks,
JRB-Bldr

 
Thanks for the replies, I will try this tommorrow at work
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top