MODIFY REPORT. Printer selection not available in Windows 7

[AndrewMozley]

Running VFP9.

I have several VFP reports (defined as .frx/.frt files). These report definitions include the specification of the destination printer. To set this I issue the command

MODIFY REPORT <reportname> NOENVIRONMENT

Within the VFP report designer I then click on File | Page Setup. This shows the selected printer.

I then click on the Page Setup button. This brings up a window which includes OK, Cancel and Printer buttons. Clicking on this last button brings up another window (also entitled Page Setup) which has a list box, captioned Name, which allows me to select a printer from the list of printers installed in Windows.

Altering the selection here, then clicking on OK a few times saves this printer selection to the .frt file. So when I next run the report it is sent to the printer I have selected. This is what happens under Windows XP.

Under Windows 7 however, going through the same process, (File | Page Setup, then click on Page Setup button) does indeed bring up a Page Setup Window, but there is then no Printer button on that window, so I am unable to select a printer to be associated with that report.

Why is this, and how can I specify the destination printer for a report which I am defining in Windows7?

 

[Olaf Doschke]

This is a change of Windows, not of VFP. But that doesn't solve your problem.

Simplest Solution without a hack:
1. Uncheck "Save Printer environment", Save the report
2. Change default printer in Windows to the one you want to save in the frt
3. Open the report. "Printer" will display that default printer. Now check "Save printer environment"

And of course you can simply hack the frt by opening it as table.

The other solution, which is good, if you want to let a user decide with which printer to print now is:

Exclude embedded printer info in the frx/frt, instead let the user choose a printer via SYS(1037) (valid up to Windows XP) or SET PRINTER TO NAME (GETPRINTER()) (since Vista). This can also be a single menu item "Choose Printer". If the user does not use that menu item "Choose Printer", VFP prints to the default printer. The choice of a printer overrides the default printer until the next choice of a printer or untile the next application start, where it goes back to the windows default, but you can of course also save the current choice, which you can read via SET("PRINTER",2) and then set at application start.

Bye, Olaf.

 

[Mike Lewis]

Andrew,

My first question is: Wny do you want to select the printer at design time? Doing that will lock the report into a specific printer, which will cause problems if the user needs to run the application on a machine that doesn't have that printer installed, or if they simply replace the printer with a different model.

However, if you have a good reason to force the user to use a particular printer, the usual way of doing that is to issue SET PRINTER TO NAME <printer driver> before you run the report (and, if applicable, set it back to what it was before afterwards).

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[AndrewMozley]

Thanks, Olaf, Mike

Mike : This is a facility that I am providing to my users. I want them to be able to specify where (in general) they want their sales invoices (say) to go. So, when they tell me "Design sales invoice (format) INV1" and click on my button, "Specify printer", I execute the MODIFY PRINTER statement which fires up the VFP report designer. I then rely on the fact that their
use of the report designer, File | Setup and all, has the desirable side-effect that it saves the name of the destination printer in the .frt, and uses that printer as the output device on all the subsequent sales orders which are printed.

It is in fact a facility for my old DOS application to print to Windows printers, using a VFP report layout. It has been working happily on Windows XP for a few years.

 

[Olaf Doschke]

OK, that's kind of misusing the report designer a bit, but I see your problem with replacing it.

It's maybe not just only the printer, but also it's compartment and pagey orientation etc. Ideally you need SYS(1037) as it was up to XP.

The workaround to edit the report twice and setting windows default in between is not applicable to end users, so you have to roll your own change of the frx/frt Expr Memo, using GETPRINTER() for the printer and SYS(1037,1) for other page setup options.

A well known solution also is to setup a windows printer several times with several individual settings of compartment, orientation, resoluion, color etc. and use that to switch between printers or also settings of the same printer by the different printer names you setup on the windows OS level.

Bye, Olaf.

 

[Mike Lewis]

Andrew,

So, you are saying that you are giving the user a way of modifying the report, and that, as part of that process, they will need to choose the printer at design time.

In that case, I would think the easiest solution is to prompt the user for the printer from within your program (using GETPRINTER() or SYS(1037)); then do the MODIFY REPORT; then, after they have finished modifying the report, you programmatically hack the FRX file to insert the printer name. If you need more details about how to perform this last step, just say so, and I (or Olaf) will oblige.

By the way, the NOENVIRONMENT clause is not relevant to this discussion. The clause affects the data environment, not the printer environment.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[JRB-Bldr]

I then rely on the fact that their use of the report designer, File | Setup and all, has the desirable side-effect that it saves the name of the destination printer in the .frt, and uses that printer as the output device on all the subsequent sales orders which are printed.

There are at least 2 problems with that approach that I can see depending on the circumstances.

1. If you are using Report Form's which are common to all users, then one user may set it up to print to a specific printer where another user may not have that printer defined in the same manner on their own specific workstation - thereby causing a problem.

2. Having a printer 'hard defined' in the Report Form makes problems if a printer is replaced with a new printer (due to printer failure, etc.) and the new printer should be named differently to the network.

It would be much better to leave the printer definition totally out of the Report Form.

Then if you wanted to save off a user-specific configuration of which printer to use, do so into a data table and then have your VFP application look into that configuration file and set that report-specific printer up for use when that report is to be printed.

In that way, how one user set the report to print would not necessarily affect the other users.

Good Luck,
JRB-Bldr

 

[AndrewMozley]

Thanks Olaf, Mike.

I guess I shall have to use GETPRINTER() and hack the .frx/.frt file to specify the printer. I have indeed done that sort of thing before, but I am a lazy fellow, and when I discovered it could be done for free I had been happy to let the report designer under Windows XP do it !


Thanks also, jrb, for your interest in the rather more general design issue. I shall explain.

For this project there is no problem in specifying the printer as part of the report; there is only one user and all sales invoices go to the same printer. It is only when the printer is replaced (as has just happened) that the user needs to change the specification of where the output is to be sent.

The printer has got to be specified somewhere, and it might as well be on the report form, where VFP can pick it up. The program which automatically prints these invoices (and purchase order &c – which may go to different printers) runs in the background, so there is not the option of prompting with a dialogue to select the printer.

We do in fact have a reprint facility. This is user-initiated, and in this case we do prompt for destination (pdf printer, local printer &c).

Andrew

 

[Olaf Doschke]

If there is only one printer anyway, besides pdf, you may simply make that the windows default and keep it off the report. Then a printer change has no effect on the printing and the next printer will also just be default and be used by VFP.

In cases users are prompted for choosing a printer SET PRINTER TO NAME (GETPRINTER()) is all you need. No FRX changes.

Bye, Olaf.

 

[JRB-Bldr]

It seems like all of us are saying the somewhat the same thing:
Do SOMETHING OTHER THAN put the printer definition in the Report Form.

Good Luck,
JRB-Bldr

 

[AndrewMozley]

Thanks Olaf.

One supplementary question. I see that the .frx/.frt file has not only a line specifying DEVICE, but also a line specifying OUTPUT - which specifies the Port for the printer.

If I persist in putting the printer name in the Expr memo field, ought I also to update the line which says OUTPUT= ?

I imagine I would need to use APRINTERS() to establish that. Although I can see that SET PRINTER TO
works quite happily with the printer name only.

Andrew

 

[Olaf Doschke]

>Although I can see that SET PRINTER TO works quite happily with the printer name only.

Yes it does. That's also a reason I stated you can uncheck storing printer info in the rerpot designer, no info needs to be present in the frx. You just specify SET PRINTER TO NAME (GETPRINTER()) and every configuration set up in windows in conjunction with that printer name is used, port, paper size, paper tray/compartment, color/grayscale, dpi resolution etc. Your users only need to configure the printer with windows.

And that also works, if they need several configurations to switch between. You can add a printer more than once, as amny times as you want to make different configuration setups. Give the windows printer names a meaning, eg TRAY1BLACK, TRAY1COLOR, TRAY2BLACK, TRAY2COLOR etc. and you or yxour users can switch between any set of configuration options just by the name.

Bye, Olaf.

 

[Mike Lewis]

On another point, Olaf mentioned this line of code:

SET PRINTER TO NAME (GETPRINTER())

That's fine, but personally I would do this instead:

lcPrinter = GETPRINTER()
IF NOT EMPTY(lcPrinter)
  SET PRINTER TO NAME (lcPrinter)
  
  * Do your report or other printing here

ENDIF

The point is that, if the user cancels out of the printer dialogue, you want to skip the printing. I know this is probably obvious, but it's worth mentioning anyway.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy