Link to home
Start Free TrialLog in
Avatar of colinasad
colinasadFlag for United Kingdom of Great Britain and Northern Ireland

asked on

How do I immediately call up the printer dialog window when I open an Access report?

I am developing an Access (adp) project as a front end to a SQL Server database.
I have created an Access Report to print a customer order, and I can open this report from the underlying Form containing the customer order.
I have the Report displayed in "Print Preview" mode where the user can then select the printer icon to launch the printer dialog window. I would like to edit the Report's "On Current" procedure so that the printer dialog window is automatically opened when the Report is displayed.
This would make life easier for the operator and hopefully also solve another slight problem. I try to keep the underlying Order Form "modal" so that users don't wander off-track. Unfortunately this prohibits the user from interacting with the Report when it is opened. If I open the Report in "popup" and "modal" modes I can work with the report but lose the printer icon.
How do I call the print dialog window?

Many thanks. Colin.
Avatar of Vadim Rapp
Vadim Rapp
Flag of United States of America image

Here's the code that will work:

  DoCmd.RunCommand acCmdPrin

You'll have to give a thought to what report's or report section event to put it into, and how to run it only once. Note that reports don't have OnCurrent event.
SOLUTION
Avatar of Vadim Rapp
Vadim Rapp
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
vadimrapp1,

In Access 2007, the Report object now has a "Current" event.
;-)

Jeff
ASKER CERTIFIED SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of colinasad

ASKER

Hi Folks,
I just came on to see if there was any responses, thanks for your time and suggestions.
Jeff, I have no connections with the other user you mentioned, but it looks like he is trying to achieve exactly the same effect as me. That is ...
Click on a "Print" button on a host Form, open and display a Report (based on the underlying Form) in a pop-up, modal "preview" window and immediately (and automatically) superimpose the standard "print dialog" window so that the user can select the required printer and print the report.

I have tried using the "DoCmd.RunCommand (acCmdPrint)" in various of my Report's events but with no success. It just doesn't appear on the screen in most events (including "On Current" ) and in others where it does get displayed (eg "On Load") it is too "early" and the report hasn't properly been formatted. I even tried the "On Timer" event in the hope that I could have the "Print Preview" displayed on the screen for a second or so before bringing up the "print dialog" box, but it just didn't appear.
I will have a go at the suggestions you gave to the other user and get back to you.

Regards. Colin.
Hi Jeff,
The piece of code you suggested for the other user worked OK for me.
I guess I was taking the wrong approach in trying to control things from within the "Report" itself rather than within the "Print_Click" procedure of the host "Form". Many thanks.

2 little queries just before I close the question :
1. What role does the "DoEvents" call do in this? Its not something I have come across before and without it, the preview report window was empty. With it, I could see my expected report. I have done a quick search for "Help" on "DoEvents" but am none the wiser. I'm told it "relinquishes control to the Operating System", but can you tell me in layman's terms why it is needed in this instance?

2. My expected report does appear in a window with the "print dialog" box on top of it - perfect. But when I move the "print dialog" box around in order to see the print preview, the underlying print preview is not refreshed and the area(s) previously covered by the "print dialog" is completely blank. As the "print dialog" box is moved around more, the print preview is eventually completely wiped clean.
Not a major problem, but since I am offering the operator a chance to look at the preview before it is printed, it is a slight annoyance.
Many thanks for your help. Colin.
Colin, are you sure you tried DoCmd.RunCommand in the events of the report? All the events you mentioned, OnTimer, OnCurrent, OnLoad - they exist for the forms, but not for the reports. You need to put this code in the report, not in the form that calls the report.
Hi vadimrapp1,
I was indeed using the Events in the Report rather than the underlying host Form. I had opened the Report in Design View and was selecting the Events from the Properties pane.
I did not have much success with that strategy, but when I used the piece of code Jeff provided (placed in my "Print" command in my host Form) I achieved the effect I was after (apart from the minor glich mentioned as point 2 in my previous post).
Regards. Colin.
vadimrapp1,

  "All the events you mentioned, OnTimer, OnCurrent, OnLoad - they exist for the forms, but not for the reports."
Again, These properties DO exist for Reports in Access 2007, which is what colinasad is using.
;-)

Jeff
Thanks Jeff, I see.

Curious, how can OnTimer event work in a report.
colinasad,

On Point 1:
"DoEvents" will make the code wait until the previous operating has finished before continuing.
If I left it out, the Dialog box pops up on top of the Report, but the report is Blank.

On Point 2:
Yeah, it is funny, I got it to.
The only explanation is that this might be happening because the dialog box is modal.

JeffCoachman
Thank you both for your help.
Apart from the minor "Point 2" its working well.
I've tried to share the points fairly.
Thanks & regards.
vadimrapp1.

"Curious, how can OnTimer event work in a report."
Flashing controls immediately comes to mind.

As you probably know, the functionality of Forms and Reports is converging.

Whether this is good or bad, I think, remains to be seen.

I personally think that the functionality should remain somewhat separated.
If not, then why bother having two separate objects?

We have seen lots of questions here from new users wanting to make a report act like a Form and vice versa.
This always causes some confusion.

I think the reason this was done was that a lot of people wanted the Reports to be more "Interactive".
(Click a button on the report to change the Sort, have Clickable Hyperlinks, ...ect)

In Access 2002, I wondered why Reports were given Modal and Hidden properties, now I often use these properties/Events.
;-)

Jeff