Print Setup

[Ollie]

My users find it strange that they have to select a Printer when all they want to do is Preview first (That is complicated by the fact that the Select Printer Dialog box actually says "Print")

I have to make the user "Select a Printer" before the preview, because in the preview screen there is no option to "Select a Printer"

Is there a way around this? i.e. Show the previewed Output and then let the user select a printer, change properties etc. and then print.

[Antonio Linares]

Ollie,

If you do:

Code: Select all  Expand view  RUN

PRINT oPrn PREVIEW
   PAGE
      oPrn:Say( 2, 2, "Hello" )
   ENDPAGE
ENDPRINT


then the preview will be shown and no request to select a printer will be done, as FWH will use the default selected printer

[Rick Lipkin]

Antonio

I think what Ollie is asking is that the only time we get a chance to get the printers is before the preview is run ..

It would be nice ( if possible ) that there could be a getprinters dialog in rpreview and another icon added to the preview tool bar to chose the printer after the output has gone to preview.

Thanks
Rick Lipkin
SC Dept of Health, USA

[R.F.]

I think it could be difficult because the metrics for the preview are taken from the current default printer driver.

To choose the printer AFTER the preview is shown, you need an "independent" device, which is difficult to implement since you need basic metrics for the printing calculations

The easy way would be to REBUILD the report once showed in the preview, I mean, you add the printer choose dialog from the preview, and then you will build the report again WITHOUT previewing and send it right to the printer

[James Bott]

Rene is right, the preview is a preview of what the report will look like on a specific print device, and then when you wish to print to a different device, you need to rebuild the report. If you change the print device after the preview, this may have the undesirable side effect of the actual printed report not being exactly the same as the preview. The user will, of course, blame the program.

A better option is to provide the standard File-Printer Setup on the menu and also display the current printer name on the message bar. It can also be displayed on the print button tooltip. This way the user can easily see what the application's currently selected printer is. They will learn to select a printer before generating a preview.

I don't recommend asking the user to select a printer before each report. This is tedious for the user. The program should make some basic assumptions based on probability. What is the probability that the user doesn't want to use the current printer? Better yet, what is the probabilty that the user doesn't want to use the printer that they just used last time? An even smarter program would keep track of which printers each user uses for each report, then assume they want to use the same one next time. A really smart program would keep track of which printer was used the last ten times. If the user printed to printer A nine times then to printer B on the tenth time, which printer is the user most likely to use on the 11th time?

Probability is not the same as possibility. Just because a user MIGHT want to do something doesn't mean that it is likely. When the user prints to the same printer 9 out of 10 times, asking the user which printer they want every time they print is not a good interface design. Maybe you could ask them the first 5 or 10 times, then after that always make an assumption based on probability and not ask anymore.

Less is more. No matter how great you think your interface is, less of it would be better.

James

[rspilon]

The very nature of enhanced metafiles allows device independence on playback due to the correct information being recorded in metafiles via device abstraction.

The only limitation is the destination device on playback - ie - resolution et al.