Printing a report defaulted to Print Preview crashes Access 2007

  • Thread starter Thread starter Rod Plastow
  • Start date Start date
R

Rod Plastow

Hi,

Has anyone else experienced this? More important, has anyone got a fix?

Reports designed with the default view set to 'Print Preview' crash Access
2007 when I attempt to print. Being more specific:

- The report displays correctly on the screen;
- When I print Access 2007 reports that it has stopped working;
- The first page of the report however prints (but only the first page);
- If I set the default view to 'Report View' and print it everything works
as it should;
- The OS is Vista (latest updates);
- The printer is Epson Stylus Photo 1410 (latest driver as far as I know).

Why do I want to use print preview if report view works? Well MS in their
wisdom inhibited some of the report events in the latter view and in my case
the report view is incomplete as these events calculate and insert certain
data into the report.

Regards.
 
Hi Allen,

Thanks for the response. Access 2007 is SP1.

Tried your suggestion but unfortunately the problem persists. Yes
'something else must be going on here.' It's not on just one database. I
had the problem some time ago when I ported a previous version mdb into 2007.
At that time I put it down to a version incompatibility glitch. Now I have
native accdb reports displaying the same behaviour.

I have some further things to try. I open these reports as instances of
class modules. I will try using the DoCmd. I also launch the report from a
pop-up modal form. Maybe this is 'getting in the way.' The form needs to be
there because it contains user chosen parameter values. However there are
other ways of passing parameters.

I will keep this dicussion group informed of success or otherwise in case
anyone's interested.

If all fails I will suspect the Epson driver - but they are usually prettty
competent.

Rod
 
Hmm!

Just completed initial tests - still requires confirmation but the
indications are:

- Nothing to do with Epson driver;
- Nothing to do with reading parameters from an open form;
- Nothing to do with default view of 'Print Preview' per se;
- Nothing to do with launching from a pop-up modal form per se;
- Nothing to do with opening report as instance of class module per se;
- Everything to do with the combination of opening report as class instance
and launching from a pop-up modal form!


- If I create the report (with default view set to print preview) as an
instance of a class module and do this from a 'normal' form, the report
prints successfully.
- If I create the report (with default view set to report view) as an
instance of a class module and do this from a pop-up modal form, the report
prints successfully. I can even switch to print preview before printing.
- If I create the report using DoCmd with acViewPreview from a pop-up modal
form, the report prints successfully.
- However if I create the report (with default view set to print preview) as
an instance of a class module and do this from a pop-up modal form, then when
I try to print Access stops working!

I'm wasting precious, costly Epson ink researching this so I stop here.
Hopefully Microsoft reads these posts. This is an Vista/Access 2007 fault
(can't say which as I upgraded simultaneously); it is not an XP/Access 2003
fault where the technique worked OK.

Rod
 
That's good detective work, Rod.

Can you give a little more detail of:
if I create the report (with default view set to print preview)
as an instance of a class module and do this from a pop-up
modal form, then when I try to print Access stops working!
What steps?

Does this mean you place code in the module of a popup modal form, that
instantiates a class module that opens multiple instances of a report (using
the New keyword), such that the reports are instances of variables that
exist in the class module? I'm not sure I followed the steps.

(Your tests are on A2007 SP1 on Vista.)
 
Hi Allen,

Yes, as you describe. Exactly what I am doing is:

- I have a set of command buttons on a switchboard form – one button for
each of a category of reports: GL reports; sub ledger reports; etc.

- Clicking the button displays a pop-up modal form requesting report values
such as accounting period and account. Also on this pop-up form are a set of
command buttons, one for each report.

- Before encountering this problem the report was displayed as you surmise
by using the NEW keyword for the report class module, e.g.

Private Sub btnActiveDebtorPosition_Click()
If IsNull(Me.cboPeriod) Then Exit Sub
Set m_rptActiveDrPosn = New Report_rptActiveDebtorPosition
m_rptActiveDrPosn.Visible = True
End Sub

These reports are not printed that often, they serve mainly as ad hoc
enquiries. The thinking behind using the class instancing technique was that
eventually I could provide side-by-side report comparison. (Aren’t wide
screens wonderful!) I would of course have to manage more than one object
variable to achieve this. The reason for using a default of print preview is
that most of the reports have some on format event code that does not execute
in report view. I am now changing the code to use DoCmd with acViewPreview
and abandoning the concept of side-by-side comparisons.

(BTW Report view displays full size whereas print preview displays half
size. Any ideas how to get print preview to display full size without
needing to click the body of the report with the magnifying glass?)

The version data:

Access 2007 (12.0.6211.1000) SP1 MSO (12.0.6320.5000)
OS - Vista Home Premium SP1
Epson Stylus Photo 1410 - Epson Color Printing System Version 6.10

Rod
 
Okay, I see where you are trying to go with that.

It's been a few years since I messed with multiple instances of reports, but
I never got it working satisfactorily because of the way Access messes up
filters across report instances. It seems like MS set it up so you can open
a report filtered in Print Preview, and than use SendObject or OutputTo
(actions that have no filters) and the same filter is applied. This suggests
that the filters across report instances intentionally interfere with each
other. And certainly that was my experience, as #3 and #4 here describe:
http://allenbrowne.com/bug-02.html

Since the whole point of opening multiple instances of a report is to
display different stuff, I found that to be an unproductive route.

Regarding code in the section events, that's okay for stuff that does not
extend beyond one page, but if you accumulate values across multiple pages
using the section events, you won't get good results. The events fire only
for the pages that are actually viewed/printed, so if you skip some pages
(e.g. just print pages 5 - 7 of a report), the values from the events of the
skipped pages don't accumulate properly. Therefore my preference is to avoid
using section events where possible -- reinforced by the fact that the
events don't fire at all in the new Report and Layout views.

Re your question about view sizes, it may help to get what you want if you
turn off the report's AutoResize property.
 
I'm currently experiencing the same issue. My setup is a tad
different, but same end result:

ON a subform of my switchboard, I have a button that sets a global
variable to the current invoice number - then using a DoCmd.OpenReport
using the acViewPreview parameter.

Report_Open event of my report has the following line of code:

Me.RecordSource = "Select * from vw_Invoices_Printing where
InvoiceNumber = '" & gsInvNum & "'"

Print Preview Works Fine.
Printing After that crashes Access.

Event Log Information:

Faulting application msaccess.exe, version 12.0.6211.1000, stamp
46d4aa81, faulting module unknown, version 0.0.0.0, stamp 00000000,
debug? 0, fault address 0x11290009.

It makes no sense to me. I do not seem to have this problem on my
Vista machine, for what its worth.
 
Back
Top