Can printing a report be detected in Access2000?

  • Thread starter Thread starter Alp Bekisoglu
  • Start date Start date
A

Alp Bekisoglu

Hi Experts,

I have been wondering if there is a way to detect if a report gets actually
sent to printer. Since there are no events as OnPrint if it is doable, I
guess it should be via code.

What I intend to do is to update a Yes/No field in the source table of the
report to Yes if it gets printed, nor previewed.

Any help would be highly appreciated.

Alp
 
Because there are various ways in which a report could be sent to the
printer without raising any error, yet still not print successfully (e.g.
printer was low on toner, or contained wrong paper) the only way to be
really sure is to ask the user ...

If MsgBox("Did the report print successfully?", vbYesNo) = vbYes Then
'execute your update query here
End If
 
Hi Experts,

I have been wondering if there is a way to detect if a report gets actually
sent to printer. Since there are no events as OnPrint if it is doable, I
guess it should be via code.

What I intend to do is to update a Yes/No field in the source table of the
report to Yes if it gets printed, nor previewed.

Any help would be highly appreciated.

Alp
Click to expand...

You can take advantage of the fact that the Report's Activate event
only fires if the report is previewed.

The actual starting value of intPreview depends upon if you have a
control in the report to compute [pages], i.e. = "Page " & [Page] & "
of " & [Pages].

Option Compare Database
Option Explicit
Dim intPreview As Integer

Private Sub Report_Activate()
intPreview = -1 ' If [Pages] is not used
' intPreview = -2 ' If [Pages] used
End Sub

Private Sub ReportHeader_Format(Cancel As Integer, FormatCount As
Integer)
If intPreview >= 0 Then ' If [Pages] not used
' If intPreview >= 1 Then ' If [Pages] used
MsgBox "Gone Printing"
End If
intPreview = intPreview + 1
End Sub

You can code the Report Footer Print event to update your table if
intPreview >= 0 or >= 1 (depending upon whether or not you are using
[Pages].
 
Thanks Brendan,

That definitely is a way to get any feedback. I'll use this if all else
fails (i.e. no way to detect)

Alp
 
Hi Fred,

Thanks a lot for the suggestion. I'll check this and see if it works for
me.

Alp

fredg said:
Hi Experts,

I have been wondering if there is a way to detect if a report gets
actually
sent to printer. Since there are no events as OnPrint if it is doable, I
guess it should be via code.

What I intend to do is to update a Yes/No field in the source table of
the
report to Yes if it gets printed, nor previewed.

Any help would be highly appreciated.

Alp
Click to expand...

You can take advantage of the fact that the Report's Activate event
only fires if the report is previewed.

The actual starting value of intPreview depends upon if you have a
control in the report to compute [pages], i.e. = "Page " & [Page] & "
of " & [Pages].

Option Compare Database
Option Explicit
Dim intPreview As Integer

Private Sub Report_Activate()
intPreview = -1 ' If [Pages] is not used
' intPreview = -2 ' If [Pages] used
End Sub

Private Sub ReportHeader_Format(Cancel As Integer, FormatCount As
Integer)
If intPreview >= 0 Then ' If [Pages] not used
' If intPreview >= 1 Then ' If [Pages] used
MsgBox "Gone Printing"
End If
intPreview = intPreview + 1
End Sub

You can code the Report Footer Print event to update your table if
intPreview >= 0 or >= 1 (depending upon whether or not you are using
[Pages].
Click to expand...
 
If of interest to anyone; I have solved (in a way so to speak) what I
needed.
I remembered that I am using a custom menu where I had to create a function
to display the print dialog when the printer icon is clicked. Modified the
function with a few if's using a modified version of "fIsLoaded" function by
Dev Ashish as "rIsLoaded" to check for open report names and perform the
related updates to relevant tables. Modified code given below.

Alp

'****** Code Start ********
Function rIsLoaded(ByVal strRptName As String) As Integer
'Returns a 0 if report is not open or a -1 if Open
If SysCmd(acSysCmdGetObjectState, acReport, strRptName) <> 0 Then
If Reports(strRptName).CurrentView <> 0 Then
rIsLoaded = True
End If
End If
End Function
'****** Code End ********
 
I don't see how that shows that the report was successfully printed (or even
printed at all, for that matter)
 
Hi Doug,

I know it is not a definite solution or an actual proof of printing. Reason
behind such is the fact that I'm sick and tired of users who don't update
the status upon printing say an invoice, a or many nametags, etc. and I
found the clicking of the print (a printer icon) option on the application
menu as a "definite indication of attemting to print". All it does is an
update of a yes/no field to yes. If user wants to print again, then they do
have the option to uncheck the control.

And yes, if they click cancel after the attempt, the item does not get
printed.

Just couldn't find a better way so resorted to this. But thanks for
reminding. I'm more than willing to hear any suggestions though.

Alp
 
As you've already been told, there's no reliable way, other than asking the
user.

You're correct that this is a reasonable interim check.
 
In addition to the advice you've already received, I find it useful to use a
Date/Time field rather than a Yes/No field for this kind of thing. A Null
value indicates that the record has been printed, a non-Null value indicates
that the record has been printed. You can do everything that you could have
done using the Yes/No field by letting Null values represent False and
non-Null values represent True. For example, you can select all records that
have never been printed ...

SELECT tblTest.*
FROM tblTest
WHERE (((tblTest.TestDate) Is Null))

You can select all records that have been printed ...

SELECT tblTest.*
FROM tblTest
WHERE (((tblTest.TestDate) Is Not Null))

You can also do things that you could not do with a Yes/No field. For
example, you can select all records that were printed yesterday ...

SELECT tblTest.*
FROM tblTest
WHERE (((tblTest.TestDate)>=Date()-1 And (tblTest.TestDate)<Date()))
 
Thanks again Doug. Well, at least I'm making an effort so maybe its time
users make an effort to correctly use an application as they were trained
to. :-)

Alp
 
Hi Brendan,

Thanks for your suggestion on using a date field. Well, I do have a date
field as to when the data was prepared (i.e. to indicate when the nametag
data was entered) but just wanted to keep away the ones from being reprinted
accidentally. But as indicated, no fool-proof way to detect... other than
looking over user's shoulder.

Alp
 
Back
Top