Printer Control and Print/Preview Problems

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I have two problems when printing reports.
1. By providing separate print preview and print command buttons on a form,
it is simple to preview or print reports by means of the appropriate View
parameters in the DoCmd OpenReport command strings associated with the
buttons. However, a need has now arisen for (a) multiple copies and/or (b)
the facility to send these copies to different printers, or to different
paper feed bins. DoCmd OpenReport does not offer multiple copy selection.
Nor can I see how to redirect a print or send command characters to the
printer. I note that PrintOut does enable the number of copies to be set but
it is not apparent how this can be used in conjunction with DoCmd OpenReport.

I employ a terminating argument in the OpenReport command line to determine
whether or not the report header should be output. (This is displayed on
Preview but not on Print, which is done on headed stationery.) The argument
takes the form “Preview†or “Printâ€, which is read by the report VBA, using
the OpenArgs command. (I cannot see how to read the View parameter directly,
which would save the need to pass a separate argument.) This works well for
single printer, single sheet, single feed bin situations but I am at a loss
to see how to combine printer selection, paper feed bin selection multiple
copy selection and argument transfer.

2. It is a requirement that reports be previewed before being printed. This
is achieved by interlocking the preview and print buttons on the form. The
print button is not made visible until the preview button has been clicked.
Ideally, the print button should not be made visible until the report preview
window has been closed but the preview window appears to remain under the
control of the OpenReport command and I cannot see how to determine its
status or use this to control the visibility of the print button. (I have an
IsFormOpen subroutine which will identify whether a form is open, or not, but
it is not apparent how anything like this could be used with the print
preview window, which I cannot currently identify.) I therefore have no
option but to make the print button visible as soon as the preview button is
clicked. This was just about acceptable until it was found that, if the
print button is clicked while the preview window is open, the print takes
place OK but the “Print†argument is ignored. The “Preview†argument
associated with the open preview window controls the print which, in the case
described above, means that the header is printed over the top of the
pre-printed header on the headed stationery. I need a method of making the
print command button visible only after the preview window has been closed.
This would then automatically resolve the problem of transferring the
appropriate argument with the OpenReport print command.
 
If you are using Access 2002 or 2003, you can manipulate the Printer object
before you OpenReport.

You could try setting the printer, e.g.:
Application.Printer = Application.Printers(0)
and then see if the PrintOut command respects that.

You could also try:
Application.Printer.Copies = 2
Haven't actually tried that, so it would be interesting to know how you go
following that with an OpenReport using acNormal.

Passing the view mode in the report's OpenArgs sounds like a good solution
for knowing the mode. If necessary, you can pass a delimited string in
OpenArgs, and use Split() to parse it.

If the report must be previewed, it might make sense to print it from the
preview toolbar only, i.e. don't provide a button on the form to print the
report. It would be simple enough to set the Enabled or Visible property of
a command button in the report's Open (or Close) event, but I don't see that
this approach is going to catch every case for whatever reasons underlie
your requirements to preview before printing.

If you are interested in an example of how to manipulate the Printer object
to set the printer and have the report remember that setting for next time,
download the example from this article:
Printer Selection Utility
at:
http://allenbrowne.com/AppPrintMgt.html

For older versions, see:
http://msdn.microsoft.com/archive/d...umControllingYourPrinterinMicrosoftAccess.asp
 
Many thanks for that very prompt reply. It again raised an intriguing
question that has crossed my mind several times in the past, when I got a
response from you. Do you ever go to bed?

It will take me a while to work through your suggestions but I will
certainly pass on any useful results. In the mean time, perhaps one or two
additional details will clarify the reasons for wanting to do things in the
way I have described.

The application creates invoices. The main copy is printed on headed
stationery and given to the customer but the proprietor does not wholly trust
computers (who can blame him) and wants a paper copy to stick in his filing
cabinet. The snag is that the principal printer is loaded with headed
stationery and it is therefore an expensive option to simply print a second
copy. There was a thought of replacing the printer (for unrelated reasons)
and the first suggestion was therefore to buy a new printer with multiple
feed bins. That would have required the necessary printer control characters
to be appended to the report print stream. The next thought was to install a
second printer on the system and load it with with plain paper. The software
requirements would be similar in either case. (Things were so much simpler
in the 'good old days' when all you had to do was load the dot-matrix printer
with two-part stationery.)

I will think over your suggestions to see if they provide a way of
implementing the sort of solution now required. Printer/bin selection
clearly has to be intiated from a single form and ideally be selected by
means of the print and preview buttons. I doubt whether any solution which
required preview and print to be initiated from different modules would be
acceptable.

Passing the view mode as an argument is not really a problem but it struck
me that, since the mode of display had already been selected with
acViewPreview or acViewNormal, there should not really be a need to pass an
argument as well. It should be possible to determine the mode implicitly
within the report, but I could not find a way of doing this and was therefore
forced to pass "Preview" and "Print" as explicit arguments.

The requirement to preview before print has arisen from the propensity of
certain staff (including the proprietor, although he denies it) not to read
the invoice before handing it to the customer, who often does not read it
either! Consequently, the wrong amount is paid for the wrong goods (or, if
you prefer, the right amount is paid for the wrong goods) and it can be some
time before the mistake is discovered. (That should sound just as familiar
in Australia as it does here.) Hence the new rule. Before being printed,
invoices must be previewed and checked to ascertain that they are being
issued to the correct recipient and that the amount is at least consistent
with expectations. Whether or not that will put an end to the problem is
anyone's guess.

When an invoice is previewed, the header and footer are included to provide
the operator with an on-screen facsimile of the printed version. When the
invoice is printed on headed stationery, however, the header and footer have
to be excluded or they will overprint the pre-printed details. (The reason
for not printing the whole thing on plain paper is fairly obvious. It would
consume ink at an unacceptable rate and commensurate expense.) This raises
questions in my mind as to whether your suggestion of printing from the
preview toolbar will work. The problem is to remove the header and footer.
The solution I have adopted up until now is to pass the arguments "Preview"
or "Print" with the DoCmd.OpenReport command, as already described. The
report VBA then sets the header and footer visibility true or false according
to which argument is received. That has worked fine up until today when the
user (bless him) discovered that, if the preview window is still open when
the print button is clicked, the report is printed but the "Print" argument
is ignored, or else overridden by the "Preview" argument associated with the
still open preview window. The result was overprinted headers and footers on
the invoices - another of Access's interesting little foibles. (I have
Access 2003, incidentally.)

There is another solution, if nothing else seems to work, and that it to
position the print/preview form so that the preview window overlaps it,
obscuring the print button. There would then be no way of clicking the print
button while the preview window was open - but that's a bit crude. Not being
able to control the positioning of the preview window could make it tricky to
implement satisfactorily. In any case it has something of the tail wagging
the dog about it.

I will now study your suggestions and see if I can improve the present
situation. It is a pity, in some ways, that Access will not allow developers
into its works a little more freely. As an old 'C' programmer (old in both
senses of the word) I miss the freedom to do more or less whatever I want.
On the other hand Access's high level facilities make life a great deal
easier than it used to be and I must admit that some 'C' programmers used the
earlier freedoms to wreak havoc (not me of course!)

--
Peter Hallett

PS I must try posting a question at around midday GMT. If I get an
immediate reply from you it will prove that you do not go to bed.
 
Hi Peter.

Okay, you have lots of options to consider.

The immediate problem of the report being already open when the Print button
on the form is clicked could be solved by closing it first:
If CurrentProject.AllReports(strDoc).IsLoaded Then
DoCmd.Close acReport strDoc
End If
DoCmd.OpenReport strDoc ...
I actually have a function call that does this regularly anyway, since
opening a report with a WhereCondition doesn't work properly if it's already
open, and passing OpenArgs doesn't either.

If you do end up trying to change printer bin programmatically, see:
http://support.microsoft.com/default.aspx?scid=kb;en-us;279506

I 'm not aware of a way to retrieve the print mode from the report. It's
true that the report's Activate event fires only in preview, but that
doesn't help us if the report is then printed from the preview.

Another crazy alternative would be to solve 2 reports: one with the
letterhead graphics, and one without. The biggest issue there is that if the
user does want to print from the toolbar in print-preview, you would need a
custom button that prints the other report, and then you're stuck trying to
apply the filter to just one record. Although it's easy to read the report's
Filter, Access does not maintain its FilterOn property correctly, so you
don't really know if you are supposed to apply it for the other report or
not.

It's always fun (if almost impossible) to trying to get a database to be
cope with human errors! :-)

Sleep? What, and miss out on Access? :-)
 
Back
Top