Efectos de EDCs en Diferentes Organismos

To print the report to a printer, use the TO PRINTER clause, which sends the report to the VFP default printer. To allow the user to choose the printer as well as change the printer settings, include the PROMPT clause. The following code shows how to print a report to the printer with and without the PROMPT clause.

*-- Print to the VFP default printer REPORT FORM MyReport TO PRINTER

*-- Print to a printer chosen by the user REPORT FORM MyReport TO PRINTER PROMPT

If you tried either of the two commands just described, you were probably surprised to see the report printed on the printer and displayed on the screen. Only this time, it wasn’t near as

‡

nice as with the PREVIEW clause because it just scrolled up the screen until the entire report was done. It never stopped and gave you a chance to see each page.

To stop that nasty behavior of scrolling on the screen at the same time it prints to the printer, use the NOCONSOLE clause as shown in the following code. This suppresses the echoing of the report to the screen whenever the PREVIEW clause is not used.

*-- Print to the VFP Default Printer REPORT FORM MyReport NOCONSOLE TO PRINTER

*-- Print to a printer chosen by the user

REPORT FORM MyReport NOCONSOLE TO PRINTER PROMPT

What printer?

A little clarification is warranted as to what the default printer is. Visual FoxPro has its own default printer, which isn’t necessarily the same as the Windows default printer. When VFP is first started, the VFP default printer is set to the Windows default printer. The VFP default printer can be changed through the main VFP Menu bar by selecting File | Page Setup…, by using the SET PRINTER TO NAME command, or by using the SYS(1037) function. The next time VFP is restarted, the VFP default printer is once again set to the Windows default printer.

The following code shows how to send a report to a specific printer without having to prompt the user to pick it. Often, this technique is used to send forms such as invoices or checks to a printer that is dedicated to one specific task.

*-- Remember the current VFP default printer LOCAL lcPrinter

lcPrinter = SET('PRINTER', 3)

*-- Set the Invoice Printer as the VFP default printer SET Printer TO NAME 'HP DeskJet 660'

*-- Print the report

REPORT FORM reports\pizzazz2 TO PRINTER

*-- Restore the VFP default printer SET Printer TO NAME “&lcPrinter”

Notice the SET PRINTER TO NAME command in the previous example uses quotes around the macro substitution. If you forget the quotes and the printer name includes a space, it won’t work!

Now in a real-world application, I wouldn’t hard-code the printer. What would happen if that printer happens to break or the client decides to buy a new printer? I wouldn’t want to have to build a new executable for them just for this reason. Especially if they’re hot-to-trot to get their invoices printed and out the door!

Instead, I would incorporate some type of control file into the application that lets the user assign which printer is the Check printer and which printer is the Invoice printer. You can use the GETPRINTER() function, which returns a printer name selected by the user, and then save that name in a control file. In your invoice program, grab the printer name from the control file

and use macro expansion to set the printer for the report just as I did in the previous code sample to restore the VFP default printer.

Printer “gotcha”

One of the biggest struggles with printing reports from Visual FoxPro has to do with which printer the report goes to and what printer settings it uses. I just explained how to send a report to a specific printer—but it doesn’t always work as anticipated and here’s why.

Besides the Windows default printer and the Visual FoxPro default printer, there’s a third printer to deal with—the report-specific printer. When you create a new report, the VFP Report Designer sets the report-specific printer to the same printer as the VFP default printer.

As long as that printer happens to be the same printer as the Windows default printer, you won’t have any problems. When you save the report, the Report Designer checks to see what the report-specific printer is and compares it against the Windows default printer. If the printers are the same, it doesn’t bother to save all the specific settings of the report-specific printer with the report.

However, if the report-specific printer is not the same as the Windows default printer, the Report Designer saves a bunch of information about the report-specific printer with the report definition stored in the FRX file. It’s that hard-coded information saved with the report that can cause you headaches down the road. For example, you may try to use the code shown in the previous example to print to a printer that you specify, but no matter how many times you try, the report keeps going to the wrong printer. The reason is that it goes to the report-specific printer saved with the report definition and does not honor the printer you tried to print to with SET PRINTER TO NAME. How’s that for a great big “gotcha”?

To avoid falling into this trap, always be sure that the report-specific printer is the same printer as your Windows default printer whenever you save a report in the Report Designer.

This includes any time you modify an existing report and save it again—even if you don’t change anything. The point is, each time you save the report with the Report Designer, the comparison of printers takes place and the subsequent hard-coded printer information gets saved in the report definition if the printers are different.

As mentioned earlier, the current VFP default printer is used as the report-specific printer when you first create a new report. To change the report-specific printer from within the Report Designer, select File | Page Setup… from the main VFP Menu bar to invoke the Page Setup dialog. From this dialog, select the Print Setup… command button to invoke the Print Setup dialog where you can select a printer to assign to the report. Remember, if the printer you select happens to be the same printer as the Windows default printer, the Report Designer won’t bother to save any of the special hard-coded printer information with the report.

All this sounds very complex and is a sleeping giant waiting to cause major problems.

The first time you forget to make sure the report-specific printer matches the Windows default printer will be the same time you build a new executable for your client, deliver it, and then go on a weeklong vacation. By the time you get back from your nice relaxing vacation, all hell has broken loose and you’ve got one very irate client!

Later, in the section titled “Eliminating printer-specific information,” I’ll show you a way to comment out any hard-coded printer information saved with a report so you can be assured that your vacation won’t come to a screeching halt—at least not because of a printer issue!

‡

‡