How do I flag a successful print?

[Randall Arnold]

Okay, so the Print event of a Detail occurs *before* printing; but I need to
know that printing has already occurred. I can find no event that fires or
property that's flagged *after* the user has sent a report to the printer.
Apparently even PrintCount is useless in this regard.

Anyone have any suggestions?

TIA,

Randall Arnold

 

[fredg]

Okay, so the Print event of a Detail occurs *before* printing; but I need to
know that printing has already occurred. I can find no event that fires or
property that's flagged *after* the user has sent a report to the printer.
Apparently even PrintCount is useless in this regard.

Anyone have any suggestions?

TIA,

Randall Arnold

When the printed report is in your hand is about the only way I know
of that you will know that it has been successfully printed. This has
been asked repeatedly.

 

[Randall Arnold]

Ah-- another of those popular features that just can't make it into the
program. I have some bad news to pass on to my client... : (

Randall Arnold

 

[Marshall Barton]

Come on, be reasonable Randall. There is no way to tell if
anything has been printed successfully. The toner may be
too low to produce a readable result, the paper could be to
wrinkled to use, etc, etc, etc...

As Fred stated, only after a person has looked at the
printout and declared it acceptable can it be said to have
been printed.

When I have to do this kind of thing, I like to add a
date/time stamp field to the one-side table in the report's
record source. Then the print report button on a form can
use an Update query based on the report's filtering to set
the field to Now(). The report can then be filtered on that
time stamp value and the presence of a time stamp can be
used to indicate that an attempt was made to print the data.
If the report did not print acceptably or if someone lost it
or ..., you can always go back and run it again.
--
Marsh
MVP [MS Access]

Ah-- another of those popular features that just can't make it into the
program. I have some bad news to pass on to my client... : (

Randall Arnold

 

[Randall Arnold]

I understand THAT. I meant some notification that the user had selected
print, closed the print dialog and the print had been sent (figured that
went without saying, sorry). As I posted previously, the user is naturally
still having to do a visual check-- I just need some sort of flag between
that visual check and the so-called Print event of the report's Detail
section. Since the user will, in this case, most likely use right-click on
the report to submit the print, a form button does me no good here. Thanks
for the attempt, though.

Randall Arnold

Come on, be reasonable Randall. There is no way to tell if
anything has been printed successfully. The toner may be
too low to produce a readable result, the paper could be to
wrinkled to use, etc, etc, etc...

As Fred stated, only after a person has looked at the
printout and declared it acceptable can it be said to have
been printed.

When I have to do this kind of thing, I like to add a
date/time stamp field to the one-side table in the report's
record source. Then the print report button on a form can
use an Update query based on the report's filtering to set
the field to Now(). The report can then be filtered on that
time stamp value and the presence of a time stamp can be
used to indicate that an attempt was made to print the data.
If the report did not print acceptably or if someone lost it
or ..., you can always go back and run it again.

 

[fredg]

Ah-- another of those popular features that just can't make it into the
program. I have some bad news to pass on to my client... : (

Randall Arnold

Well, look at it this way, even if Access were to tell you that the
report was 'sent to the printer', the printer could run out of ink,
run out of paper, the dog could have chewed the power cord, etc.,
etc., etc.

 

[Randall Arnold]

Yes. I understand. I'm handling that as one would expect (visual
verification by user). I just needed a way to know that the user had made
the *attempt*, so that I'll know when to pop up my print verification
dialog. Right now, it seems Access has no intrinsic way of flagging that
such an event has occurred; to me that's a shortcoming. So I have no idea
when it's okay to pop up my dialog.

Maybe the Printer object itself can provide a means... I'll look into that
next. What I *really* wanted to do was use the custom menus that I'm told
can be attached to a report, but I was never able to get that feature to
work so I gave up. If I'd gotten that to work, I'd have disabled the
right-click context menu and opened my verification dialog immediately after
the user clicked "print" on my drop-down menu. Or, if there's a way that I
can detect the Print command was selected from the context menu, that would
work as well.

Randall Arnold

 

[SA]

Marsh's approach is the commonly used approach.

Just a hint and note for consideration when using Now() vs. Date() when time
stamping records for those folks reading this thread.

If you use Now() which also puts in a time value along with the date in the
record, and later want to select records using a common date span approach
(e.g. Between 4/1/2004 and 4/10/2004), records that have a time stamp based
on Now() would have a value something like 4/10/2004 11:04:56 AM. Such a
record would NOT be picked up when using the previous date span range to
pull records. This is because the simple date 4/10/2004, would, in full
date time format, have a value of 4/10/2004 12:00:00 AM, which of course is
less than the value of 4/10/2004 11:04:56 AM. As a result you have to make
sure that when you choose Now() as the time stamp that you either expand
your date span selection methods that are based on date alone to be one day
greater (e.g. 4/1/2004 to 4/11/2004) to pull in all the values from the
target end day of 4/10/2004 or convert the value of the time stamp field to
a date only by doing something like:
CVDate(Format([MyDateTimeStampField],"mm/dd/yyyy")) when pulling records
based on date span selection criteria alone.

In SQL Server, use the CAST function to adjust Time stamp or date/time
fields to dates alone if doing similar date span pulls.
--
Steve Arbaugh
ACG Soft
http://ourworld.compuserve.com/homepages/attac-cg

Come on, be reasonable Randall. There is no way to tell if
anything has been printed successfully. The toner may be
too low to produce a readable result, the paper could be to
wrinkled to use, etc, etc, etc...

As Fred stated, only after a person has looked at the
printout and declared it acceptable can it be said to have
been printed.

When I have to do this kind of thing, I like to add a
date/time stamp field to the one-side table in the report's
record source. Then the print report button on a form can
use an Update query based on the report's filtering to set
the field to Now(). The report can then be filtered on that
time stamp value and the presence of a time stamp can be
used to indicate that an attempt was made to print the data.
If the report did not print acceptably or if someone lost it
or ..., you can always go back and run it again.

 

[Randall Arnold]

I just realized the wording of my original subject was misleading. D'oh! I knew better than that..

Randall Arnold

 

[fredg]

Yes. I understand. I'm handling that as one would expect (visual
verification by user). I just needed a way to know that the user had made
the *attempt*, so that I'll know when to pop up my print verification
dialog. Right now, it seems Access has no intrinsic way of flagging that
such an event has occurred; to me that's a shortcoming. So I have no idea
when it's okay to pop up my dialog.

Maybe the Printer object itself can provide a means... I'll look into that
next. What I *really* wanted to do was use the custom menus that I'm told
can be attached to a report, but I was never able to get that feature to
work so I gave up. If I'd gotten that to work, I'd have disabled the
right-click context menu and opened my verification dialog immediately after
the user clicked "print" on my drop-down menu. Or, if there's a way that I
can detect the Print command was selected from the context menu, that would
work as well.

Randall Arnold

Randall,
Does this help?

Code the following 2 report sections as indicated:

Private Sub Report_Activate()
intPreview = -1
End Sub
==============

Private Sub ReportHeader_Format(Cancel As Integer, FormatCount As
Integer)
If intPreview >= 0 Then
MsgBox "Printing"
End If

You can replace the MsgBox and instead Update a field in a table with
the time, using Now() if you want.

The Activate event only runs if the report is previewed, so....
If the report is only previewed, there is no message.
If the report is previewed then printed, you'll get a message.
If the report is printed without preview, you'll get a message.
But again, until you have it in hand, there is no guarantee it's been
successfully printed.

 

[Randall Arnold]

Hmmm... that looks like a really nice workaround! Thanks Fred-- I'll try
it!

Randall Arnold

 

[Randall Arnold]

Well, that doesn't work. As soon as the form opens the msgbox pops up,
before I even get a chance to try printing. I'm still stuck at the same
place.

I wish I could find a decent tutorial on adding toolbars/menus to reports,
because that would solve my problem. I've tried the one MS publishes and
another I found on a consultant's site but both were either omitting crucial
information or possessing an error. Sigh... back to the drawing board...

Randall Arnold

 

[fredg]

Well, that doesn't work. As soon as the form opens the msgbox pops up,
before I even get a chance to try printing. I'm still stuck at the same
place.

I wish I could find a decent tutorial on adding toolbars/menus to reports,
because that would solve my problem. I've tried the one MS publishes and
another I found on a consultant's site but both were either omitting crucial
information or possessing an error. Sigh... back to the drawing board...

Randall Arnold

What form?
This is for a Report.
I see, in re-reading the code just now, I forgot to mention you must
Dim intPreview up in the declaration section of the code sheet.

Option Compare Database
Option Explicit
Dim intPreview as integer
=============
Then add the Report Activate and the Report Header code.
Sorry.

 

[Randall Arnold]

"Form" was simply a typo on my part. I meant report.

I already added the dim statement, since I was already using option
explicit. I also tried the code in a Knowledge Base article (154894) which
was similar to yours, and it didn't work as advertised. No matter what, the
report is flagged as printed BEFORE it prints. Same problem I've
encountered throughout this maddening ordeal... : (

Randall Arnold

 

[SA]

Randall:

Unfortunately, this is an historic and ongoing problem for Access reports;
there's really no way to work around it other than the suggestion noted
below. The issue is that there really is no "Print" event. Even if you
use the OnActivate event to denote when the report is previewed, then the
user can still send the report to print from there and no addition event is
fired.

The only real way to assure that you know when a report is printed vs
previewed, is to a.) create print and preview buttons on your form that
calls the report. only run your update code from the print button. b.)
create custom tool bars and menu items to use with your report that elminate
the standard Print option so that when a report is in preview, the user
can't print from there, i.e. they have to close the report to print (from
your form to print) or create your own Print function in a general module
that your custom toolbars and menus call when the print item is selected,
and run your update code after the print command if there's otherwise no
error encountered.

Its a hack, but really that's the only way to do it. On Activate just
won't do the trick.
--
Steve Arbaugh
ACG Soft
http://ourworld.compuserve.com/homepages/attac-cg

"Form" was simply a typo on my part. I meant report.

I already added the dim statement, since I was already using option
explicit. I also tried the code in a Knowledge Base article (154894)
which was similar to yours, and it didn't work as advertised. No matter
what, the report is flagged as printed BEFORE it prints. Same problem
I've encountered throughout this maddening ordeal... : (

Randall Arnold

 

[Duncan Bachen]

Okay, so the Print event of a Detail occurs *before* printing; but I need to
know that printing has already occurred. I can find no event that fires or
property that's flagged *after* the user has sent a report to the printer.
Apparently even PrintCount is useless in this regard.

Anyone have any suggestions?

TIA,

Randall Arnold

Little late to the party, but I read the rest of the thread. I'm
posting this on the top level, because my suggestion doesn't involve
the activate event.

What we do with one of our reports is to the use the Report Close
event and ask the user if it successfully printed. Granted, using a
scenario such as this, you are relying on the user to truthfully
answer the question, so it's not good for a extremely serious security
model.

In our case, we set a flag when the ReportFooter is printed, then
check for the presence of the flag in the closing of the report and
act accordingly.

In this scenario, we flag the associated records with the print date,
as well as the trackingID which is assigned to the printout.

Our report will continue to include those records who have not been
printed until it finally gets a successful printing.

This could easily be adapted to store usernames, or to have a master
table which saves the report name + report time printed, or any number
of other things.

Again though, it's relying on the user to successfully and truthfully
answer the question.

** Code **
Private Sub ReportFooter_Print(Cancel As Integer, PrintCount As
Integer)
fWasPrinted = True
End Sub

Private Sub Report_Close()
Dim src As String
Dim intResponse As Integer
Dim lngLastTrackingID As Integer

If fWasPrinted Then
intResponse = MsgBox("Did the audit report print out ok?",
vbQuestion + vbYesNo, _
"Print out ok?")
If intResponse = vbYes Then
lngLastTrackingID = ELookup("[VoidEditTrackingID]", "[System]") + 1
src = "UPDATE Audit SET Audit.PrintedOn = Now(), Audit.TrackingID =
" & lngLastTrackingID & " WHERE (Audit.PrintedOn Is Null);"
DoCmd.SetWarnings False
DoCmd.RunSQL (src)
src = "UPDATE System SET System.VoidEditTrackingID = " &
lngLastTrackingID
DoCmd.RunSQL (src)
DoCmd.SetWarnings True
End If
End If
End Sub
** End Code **
-D

 

[Randall Arnold]

Thanks Duane. I'm at my wit's end so I'll give it a shot, but the method
still looks so similar to what I've already tried that I'm a bit confused.
The only difference is you use the Footer where others use the Header-- I'm
hoping that makes enough difference.

What I've experienced is that the user can preview the report, NOT print at
all, and the flag is *still* set-- so they'd get the dialog whether they
tried to print or not. What I've learned over the course of this ordeal is
that the so-called "Print" events fire BEFORE a print, and in my case
they're firing even if the Print command is never selected (which makes
absolutely no freaking sense to me-- Microsoft, are you listening???). My
prior assumption had been that the Format event handles all preprinting
tasks, but that seems to not be the case.

So I'm bewildered how your code can work, just based on what's been
occurring to me...

Randall Arnold

Okay, so the Print event of a Detail occurs *before* printing; but I need
to
know that printing has already occurred. I can find no event that fires
or
property that's flagged *after* the user has sent a report to the
printer.
Apparently even PrintCount is useless in this regard.

Anyone have any suggestions?

TIA,

Randall Arnold

Little late to the party, but I read the rest of the thread. I'm
posting this on the top level, because my suggestion doesn't involve
the activate event.

What we do with one of our reports is to the use the Report Close
event and ask the user if it successfully printed. Granted, using a
scenario such as this, you are relying on the user to truthfully
answer the question, so it's not good for a extremely serious security
model.

In our case, we set a flag when the ReportFooter is printed, then
check for the presence of the flag in the closing of the report and
act accordingly.

In this scenario, we flag the associated records with the print date,
as well as the trackingID which is assigned to the printout.

Our report will continue to include those records who have not been
printed until it finally gets a successful printing.

This could easily be adapted to store usernames, or to have a master
table which saves the report name + report time printed, or any number
of other things.

Again though, it's relying on the user to successfully and truthfully
answer the question.

** Code **
Private Sub ReportFooter_Print(Cancel As Integer, PrintCount As
Integer)
fWasPrinted = True
End Sub

Private Sub Report_Close()
Dim src As String
Dim intResponse As Integer
Dim lngLastTrackingID As Integer

If fWasPrinted Then
intResponse = MsgBox("Did the audit report print out ok?",
vbQuestion + vbYesNo, _
"Print out ok?")
If intResponse = vbYes Then
lngLastTrackingID = ELookup("[VoidEditTrackingID]", "[System]") + 1
src = "UPDATE Audit SET Audit.PrintedOn = Now(), Audit.TrackingID =
" & lngLastTrackingID & " WHERE (Audit.PrintedOn Is Null);"
DoCmd.SetWarnings False
DoCmd.RunSQL (src)
src = "UPDATE System SET System.VoidEditTrackingID = " &
lngLastTrackingID
DoCmd.RunSQL (src)
DoCmd.SetWarnings True
End If
End If
End Sub
** End Code **
-D

---------------------
Duncan Bachen (dbachen@NOSPAM_olehansen.com)
Director of IT
Ole Hansen and Sons Inc.
---------------------

 

[SA]

Randall:

Duncan's method would generally work, with one exception, that being that if
the user navigates to the end of the report in preview, his code will still
fire when the report is closed. Now of course the user should click "No"
the report didn't print, but again, you could have user who simply clicks
yes.

Related to the "Print" event, it fire when the output is fully preped and
output sent to the Windows GDI subsystem, either in display or in actual
printing of output. Since it basically recognizes when output is "sent" its
always going to occur BEFORE the actual output is rendered by GDI either to
the display or to the printer........
--
Steve Arbaugh
ACG Soft
http://ourworld.compuserve.com/homepages/attac-cg

Thanks Duane. I'm at my wit's end so I'll give it a shot, but the method
still looks so similar to what I've already tried that I'm a bit confused.
The only difference is you use the Footer where others use the Header--
I'm hoping that makes enough difference.

What I've experienced is that the user can preview the report, NOT print
at all, and the flag is *still* set-- so they'd get the dialog whether
they tried to print or not. What I've learned over the course of this
ordeal is that the so-called "Print" events fire BEFORE a print, and in my
case they're firing even if the Print command is never selected (which
makes absolutely no freaking sense to me-- Microsoft, are you
listening???). My prior assumption had been that the Format event handles
all preprinting tasks, but that seems to not be the case.

So I'm bewildered how your code can work, just based on what's been
occurring to me...

Randall Arnold

Okay, so the Print event of a Detail occurs *before* printing; but I need
to
know that printing has already occurred. I can find no event that fires
or
property that's flagged *after* the user has sent a report to the
printer.
Apparently even PrintCount is useless in this regard.

Anyone have any suggestions?

TIA,

Randall Arnold

Little late to the party, but I read the rest of the thread. I'm
posting this on the top level, because my suggestion doesn't involve
the activate event.

What we do with one of our reports is to the use the Report Close
event and ask the user if it successfully printed. Granted, using a
scenario such as this, you are relying on the user to truthfully
answer the question, so it's not good for a extremely serious security
model.

In our case, we set a flag when the ReportFooter is printed, then
check for the presence of the flag in the closing of the report and
act accordingly.

In this scenario, we flag the associated records with the print date,
as well as the trackingID which is assigned to the printout.

Our report will continue to include those records who have not been
printed until it finally gets a successful printing.

This could easily be adapted to store usernames, or to have a master
table which saves the report name + report time printed, or any number
of other things.

Again though, it's relying on the user to successfully and truthfully
answer the question.

** Code **
Private Sub ReportFooter_Print(Cancel As Integer, PrintCount As
Integer)
fWasPrinted = True
End Sub

Private Sub Report_Close()
Dim src As String
Dim intResponse As Integer
Dim lngLastTrackingID As Integer

If fWasPrinted Then
intResponse = MsgBox("Did the audit report print out ok?",
vbQuestion + vbYesNo, _
"Print out ok?")
If intResponse = vbYes Then
lngLastTrackingID = ELookup("[VoidEditTrackingID]", "[System]") + 1
src = "UPDATE Audit SET Audit.PrintedOn = Now(), Audit.TrackingID =
" & lngLastTrackingID & " WHERE (Audit.PrintedOn Is Null);"
DoCmd.SetWarnings False
DoCmd.RunSQL (src)
src = "UPDATE System SET System.VoidEditTrackingID = " &
lngLastTrackingID
DoCmd.RunSQL (src)
DoCmd.SetWarnings True
End If
End If
End Sub
** End Code **
-D

---------------------
Duncan Bachen (dbachen@NOSPAM_olehansen.com)
Director of IT
Ole Hansen and Sons Inc.
---------------------

 

[Rick Brandt]

A variation on an idea that (Larry Linson?) once posted.

Have a special button that prints the report. This button would set a
public variable to a random string or number that will NOT be set when the
report is printed by any means other than when using this special button.
The button sets this variable and then prints directly to the printer with
no preview.

Your report includes the random value in the report footer and the user is
required to certify that the report printed by entering this value into a
confirmation form that pops up after pressing your button.

The only way they will be able to enter the correct value is by retrieving
it from the hard copy produced by the printer.

Thanks Steve-- that may explain my predicament. My test report contained

only one record, thus one page. Obviously merely previewing the report
took the user (me) to the end.

This is one of the singularly most frustrating dilemmas I have ever

encountered in over 8 years of programming in Access, simply because of the
client's needs and expectations. I wish it had come up when I beta tested
2003 so I could have proposed a solution for the next version. Maybe I can
get in on the 2005 alpha and start screaming.

MS employees, if any of you are reading: we developers need a new event

for reports in the next version of Access. Call it AfterPrint.

Randall Arnold

----- SA wrote: -----

Randall:

Duncan's method would generally work, with one exception, that being that if
the user navigates to the end of the report in preview, his code will still
fire when the report is closed. Now of course the user should click "No"
the report didn't print, but again, you could have user who simply clicks
yes.

Related to the "Print" event, it fire when the output is fully preped and
output sent to the Windows GDI subsystem, either in display or in actual
printing of output. Since it basically recognizes when output is "sent" its
always going to occur BEFORE the actual output is rendered by GDI either to
the display or to the printer........
--
Steve Arbaugh
ACG Soft
http://ourworld.compuserve.com/homepages/attac-cg

Thanks Duane. I'm at my wit's end so I'll give it a shot, but the method
still looks so similar to what I've already tried that I'm a bit confused.
The only difference is you use the Footer where others use the Header--
I'm hoping that makes enough difference.

What I've experienced is that the user can preview the report,

NOT print
at all, and the flag is *still* set-- so they'd get the dialog whether
they tried to print or not. What I've learned over the course of this
ordeal is that the so-called "Print" events fire BEFORE a print, and in my
case they're firing even if the Print command is never selected (which
makes absolutely no freaking sense to me-- Microsoft, are you
listening???). My prior assumption had been that the Format event handles
all preprinting tasks, but that seems to not be the case.

So I'm bewildered how your code can work, just based on what's

been
occurring to me...

Randall Arnold
On Tue, 20 Apr 2004 20:02:35 -0500, "Randall Arnold"
Okay, so the Print event of a Detail occurs *before* printing; but I need
to
know that printing has already occurred. I can find no event that fires
or
property that's flagged *after* the user has sent a report to the
printer.
Apparently even PrintCount is useless in this regard.
Anyone have any suggestions?
TIA,
Randall Arnold
Little late to the party, but I read the rest of the thread. I'm
posting this on the top level, because my suggestion doesn't involve
the activate event.
What we do with one of our reports is to the use the Report Close
event and ask the user if it successfully printed. Granted, using a
scenario such as this, you are relying on the user to truthfully
answer the question, so it's not good for a extremely serious security
model.
In our case, we set a flag when the ReportFooter is printed, then
check for the presence of the flag in the closing of the report and
act accordingly.
In this scenario, we flag the associated records with the print date,
as well as the trackingID which is assigned to the printout.
Our report will continue to include those records who have not been
printed until it finally gets a successful printing.
This could easily be adapted to store usernames, or to have a master
table which saves the report name + report time printed, or any number
of other things.
Again though, it's relying on the user to successfully and truthfully
answer the question.
** Code **
Private Sub ReportFooter_Print(Cancel As Integer, PrintCount As
Integer)
fWasPrinted = True
End Sub
Private Sub Report_Close()
Dim src As String
Dim intResponse As Integer
Dim lngLastTrackingID As Integer
If fWasPrinted Then
intResponse = MsgBox("Did the audit report print out ok?",
vbQuestion + vbYesNo, _
"Print out ok?")
If intResponse = vbYes Then
lngLastTrackingID = ELookup("[VoidEditTrackingID]", "[System]") + 1
src = "UPDATE Audit SET Audit.PrintedOn = Now(), Audit.TrackingID =
" & lngLastTrackingID & " WHERE (Audit.PrintedOn Is Null);"
DoCmd.SetWarnings False
DoCmd.RunSQL (src)
src = "UPDATE System SET System.VoidEditTrackingID = " &>> lngLastTrackingID
DoCmd.RunSQL (src)
DoCmd.SetWarnings True
End If
End If
End Sub
** End Code **
-D

 

[Randall Arnold]

Right, but you're supposing the print request always comes from a form. In some cases my client may be right-clicking on the report, selecting Print from the pop-up context menu, and bypassing any code in the form that called the report

Of course, there is a solution to that: the pop-up can be disabled. However, the client wants this option. They want printing to be available from whereever the current focus lies. For me to take it away, I needed the facts and arguments presented in this thread. My only problem there is, I'm having difficulty with things like custom menubars and pop-up modifications. The changes I want limited to a specific report for some reason are applied to the application at large (even though I cannot see anywhere in code or properties that this is applied) and not restored. So apparently I now have to go on *another* quest to figure out what's going on there

*Sigh

Randall Arnol

----- Rick Brandt wrote: ----

A variation on an idea that (Larry Linson?) once posted

Have a special button that prints the report. This button would set
public variable to a random string or number that will NOT be set when th
report is printed by any means other than when using this special button
The button sets this variable and then prints directly to the printer wit
no preview

Your report includes the random value in the report footer and the user i
required to certify that the report printed by entering this value into
confirmation form that pops up after pressing your button

The only way they will be able to enter the correct value is by retrievin
it from the hard copy produced by the printer

Thanks Steve-- that may explain my predicament. My test report containe

only one record, thus one page. Obviously merely previewing the repor
took the user (me) to the endencountered in over 8 years of programming in Access, simply because of th
client's needs and expectations. I wish it had come up when I beta teste
2003 so I could have proposed a solution for the next version. Maybe I ca
get in on the 2005 alpha and start screaming

MS employees, if any of you are reading: we developers need a new even for reports in the next version of Access. Call it AfterPrint
Randall Arnol
----- SA wrote: ----
Randall
Duncan's method would generally work, with one exception, that bein

that i
the user navigates to the end of the report in preview, his cod will stil
fire when the report is closed. Now of course the user shoul click "No
the report didn't print, but again, you could have user who simpl click

yes
Related to the "Print" event, it fire when the output is full

preped an
output sent to the Windows GDI subsystem, either in display or i actua
printing of output. Since it basically recognizes when output i "sent" it
always going to occur BEFORE the actual output is rendered by GD either t
the display or to the printer.......
--
Steve Arbaug
ACG Sof
http://ourworld.compuserve.com/homepages/attac-c

Thanks Duane. I'm at my wit's end so I'll give it a shot, but th metho
still looks so similar to what I've already tried that I'm a bi confused
The only difference is you use the Footer where others use th Header--
I'm hoping that makes enough difference

What I've experienced is that the user can preview the report

NOT print
at all, and the flag is *still* set-- so they'd get the dialog whether
they tried to print or not. What I've learned over the course of this
ordeal is that the so-called "Print" events fire BEFORE a print, and in my
case they're firing even if the Print command is never selected (which
makes absolutely no freaking sense to me-- Microsoft, are you
listening???). My prior assumption had been that the Format event handles
all preprinting tasks, but that seems to not be the case.

So I'm bewildered how your code can work, just based on what's

been
occurring to me...

Randall Arnold
On Tue, 20 Apr 2004 20:02:35 -0500, "Randall Arnold"
Okay, so the Print event of a Detail occurs *before* printing; but I need
to
know that printing has already occurred. I can find no event that fires
or
property that's flagged *after* the user has sent a report to the
printer.
Apparently even PrintCount is useless in this regard.
Anyone have any suggestions?
TIA,
Randall Arnold
Little late to the party, but I read the rest of the thread. I'm
posting this on the top level, because my suggestion doesn't involve
the activate event.
What we do with one of our reports is to the use the Report Close
event and ask the user if it successfully printed. Granted, using a
scenario such as this, you are relying on the user to truthfully
answer the question, so it's not good for a extremely serious security
model.
In our case, we set a flag when the ReportFooter is printed, then
check for the presence of the flag in the closing of the report and
act accordingly.
In this scenario, we flag the associated records with the print date,
as well as the trackingID which is assigned to the printout.
Our report will continue to include those records who have not been
printed until it finally gets a successful printing.
This could easily be adapted to store usernames, or to have a master
table which saves the report name + report time printed, or any number
of other things.
Again though, it's relying on the user to successfully and truthfully
answer the question.
** Code **
Private Sub ReportFooter_Print(Cancel As Integer, PrintCount As
Integer)
fWasPrinted = True
End Sub
Private Sub Report_Close()
Dim src As String
Dim intResponse As Integer
Dim lngLastTrackingID As Integer
If fWasPrinted Then
intResponse = MsgBox("Did the audit report print out ok?",
vbQuestion + vbYesNo, _
"Print out ok?")
If intResponse = vbYes Then
lngLastTrackingID = ELookup("[VoidEditTrackingID]", "[System]") + 1
src = "UPDATE Audit SET Audit.PrintedOn = Now(), Audit.TrackingID =
" & lngLastTrackingID & " WHERE (Audit.PrintedOn Is Null);"
DoCmd.SetWarnings False
DoCmd.RunSQL (src)
src = "UPDATE System SET System.VoidEditTrackingID = " &>> lngLastTrackingID
DoCmd.RunSQL (src)
DoCmd.SetWarnings True
End If
End If
End Sub
** End Code **
-D