Detect if an Access Report is in Preview Mode, Report Mode, or Being Sent to the Printer

How do you know if a user is viewing a report on screen or if they sent it to the printer? With this simple technique from Access MVP, Karl Donaubauer.

Detect if an Access Report is in Preview Mode, Report Mode, or Being Sent to the Printer

I've been meaning to write an article about this one since Karl Donaubauer presented it to the Access Europe User Group back on January 4, 2023.

The Video

This was just one of Karl's many tips and tricks that he presented.  If you want to watch the video, this section starts at the 28:54 mark:

The Prerequisites

Karl's code relies on the Report Header's Print event handler being called.

That can only happen on reports that have a Report Header.  The report header section does not need to be visible; it can have a height of 0.  It does need to be there, though.

The Code

Here's Karl's code as shown in the video:

Option Compare Database
Option Explicit

'Author: Karl Donaubauer

'determines if the report is sent to the printer,
'   as opposed to being opened in any screen view
Dim blnPreview As Boolean

Private Sub Report_Activate()
    'Activate only happens for screen views
    If Me.CurrentView = acCurViewPreview Then
        blnPreview = True
    ElseIf Me.CurrentView = acCurViewReportBrowse Then
        Debug.Print "Screen (aka, Report View)"
    End If
End Sub

Private Sub ReportHeader_Print(Cancel As Integer, PrintCount As Integer)
    'Print happens at page preview or print
    If blnPreview Then
        Debug.Print "Print Preview"
        Debug.Print "Sent to Printer"
    End If
    blnPreview = Not blnPreview
End Sub

Layout Mode

During the live event, Access MVP and host Colin Riddington asked whether Karl's code could distinguish reports in Layout Mode.  Karl wasn't sure when put on the spot, but he followed up with responses in the comments of the video.  Here's his final response to that question:

Colin asked if you can also detect the Layout view. Answer: only very limited. When I additionally query the corresponding constant acCurViewLayout in the Activate event, the Report view is usually reported, i.e. Layout is not recognized. Only if I open the report from the navigation pane, Activate is done twice: once with Report view feedback, once with Layout view. But, as noted in the meeting, I think this is a largely academic question, because the Layout view will hardly ever be made available to the end user.

Indeed, Layout Mode is most useful when sizing controls at design time.  I would never show a report in Layout Mode to an end user.


One important thing to keep in mind: just because the user sent a report to the printer, there's no guarantee it actually printed.

Sending a document to a printer is one of the leakiest abstractions in software.  There are so many things that can go wrong:

  • The paper could jam
  • The printer could be out of toner
  • Wrong size paper loaded
  • Wrong color paper loaded
  • Wrong type of paper loaded (e.g., plain vs. perforated vs. labels, etc.)
  • It's a virtual printer (e.g., PDFCreator)

The bottom line is that there is no way to guarantee that any report has been successfully printed without explicitly asking the user.  

In situations where it's important (e.g., printing on preprinted check stock), I'll often ask the user in the Report_Close event, something along the lines of "Did the report/checks/labels/letters/etc. print correctly?"

Unfortunately, users have been known to make mistakes occasionally, too.  (I swear!  I've seen it happen.)  So be sure you've thought about how you would undo whatever process(es) need(s) to be undone if they accidentally choose the wrong answer to that question.

External references

The Law of Leaky Abstractions
There’s a key piece of magic in the engineering of the Internet which you rely on every single day. It happens in the TCP protocol, one of the fundamental building blocks of the Internet. TCP…

Referenced articles

3 Techniques for Programming Reversible Processes
How would you recover from a large accidental UPDATE operation? You’d better be able to answer that question *before* it happens.

All original code samples by Mike Wolfe are licensed under CC BY 4.0